From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: Re: [PATCH][ACM] kernel enforcement of vbd policies via blkback driver Date: Thu, 27 Jul 2006 18:43:25 +0100 Message-ID: <1154022205.7906.50.camel@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Reiner Sailer Cc: Andrew Warfield , xen-devel@lists.xensource.com, xense-devel@lists.xensource.com, Bryan D Payne , ncmike@us.ibm.com List-Id: xen-devel@lists.xenproject.org On Thu, 2006-07-27 at 13:38 -0400, Reiner Sailer wrote: > > Harry Butterworth wrote on > 07/27/2006 01:06:50 PM: > > > On Thu, 2006-07-27 at 12:58 -0400, Reiner Sailer wrote: > > > > > > > > > Harry Butterworth 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