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 10:41:29 +0100 Message-ID: <1153993289.10340.5.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 Wed, 2006-07-26 at 18:51 -0400, Reiner Sailer wrote: > > > > > > So basically, the xenstore++ is in a stripped down secured domain > and > > someone with role-based access privileges communicates with xenstore > ++ > > to connect a resource to a domain. Xenstore++ checks the > permissions > > and sets up the connection where the protocol description to use is > an > > attribute of the resource class. The protocol is policed and if > it's > > violated then either the resource provider (BE) or consumer (FE) or > both > > get blown away. > > > > There can be generic mechanisms in xenstore++ for colouring > resources > > and grouping roles etc to do fancy MAC stuff. > > > > > > ...or something like that. > > > > Harry. > > > > Hmm... this is not how I see xenstore today. Did you discuss what it > takes to implement the "++"? > (especially the part where you suggest moving xenstore in its on > secured domain sounds very interesting) No. I didn't discuss what it would take to implement it. Personally I'd start by defining a fault-tolerant cluster architecture and then build it inside that. That would be a fair bit of work up-front but I think a lot of the significant use-cases demand it and it would have a discriminating impact on the implementation. > > Would this be a non-intrusive change to Xen? Probably not with my approach :-) > > Reiner