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

[Reiner Sailer <sailer@xxxxxxxxxx>]

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?

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