[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |