[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver



On Thu, 2006-07-27 at 13:38 -0400, Reiner Sailer wrote:
> 
> Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote on
> 07/27/2006 01:06:50 PM:
> 
> > On Thu, 2006-07-27 at 12:58 -0400, Reiner Sailer wrote:
> > > 
> > > 
> > > Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote on
> > > 07/27/2006 12:36:43 PM:
> > > 
> > > > On Thu, 2006-07-27 at 17:26 +0100, Harry Butterworth wrote:
> > > > 
> > > > > untrusted driver domain <-> trusted encryption domain <->
> > > FE-domain
> > > > >                            hypervisor
> > > > >                    trusted access control domain
> > > > 
> > > > Another argument in favour of this kind of approach is that if
> your
> > > BE
> > > > is something like a fibrechannel driver for a SAN, there isn't
> > > actually
> > > > any security on the SAN side of it so any guarantees provided by
> the
> > > > driver domain are pretty much worthless.
> > > > 
> > > > Harry.
> > > > 
> > > 
> > > We are talking about scalable, secure, and efficient local device
> > > virtualization.  
> > 
> > Even with local devices there is no security on the device side of
> the
> > device driver.  Consider the case of a locally attached sata drive
> > containing 2 partitions, one for each of two domains.  It's not
> unheard
> > of for disk drives to write the data in the wrong place.  Or read
> and
> > return the wrong block.  Happens all the time.
> > 
> 
> If you can't trust your hardware, then you cant trust a domain built
> on top of it. There is no need to convince me. If this is not a
> "fixable" problem, then such devices cannot be assumed trused.  
> 
> Either they are not shared or the risk must be mitigated (e.g., as you
> suggested by encryption/signing and another trusted proxy). 
> 
> Is this undeterministic/uncontrollable behavior considered "normal"
> operation? 

It's obviously unusual but we do see it in real life, for example, when
we test 3rd party storage controllers.

> 
> Thanks 
> Reiner


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.