WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: xsm: Consolidate xsm processing within domain control hy

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: xsm: Consolidate xsm processing within domain control hypercall.
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Tue, 4 Dec 2007 16:46:35 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>
Delivery-date: Tue, 04 Dec 2007 13:47:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C37B2EE0.10B30%gscoker@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <1196801047.19310.38.camel@lappy> <C37B2EE0.10B30%gscoker@xxxxxxxxxxxxxx>
Reply-to: ncmike@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.15+20070412 (2007-04-11)
On 04/12/07 16:20 -0500, George S. Coker, II wrote:
> A couple of things:
> 
> - For these modifications to work, updates also have to be made to the dummy
> module for XSM_ENABLE=y to compile
> 
> - I do not think these modifications are a win.  I would like to see this
> changeset reverted for the following reasons:
> 
> 1) While it may reduce the number of lines of code in the domctl hypercall,
> it won't really reduce the overall number of lines of code in the hypervisor
> if a module chooses to implement security operations on all of the donctl
> operations. 

True, but it does concentrate the code in the security module. Also,
it only requires one entry point to the security module from within
the domctrl hypercall. I think that makes the code more maintainable
and less likely that new domctl operations will bypass xsm security. 


> 2) This will also impose on the security modules the responsibility to
> acquire and hold locks on hypervisor resources.  It would seem dangerous to
> give modules this responsibility.

I don't see it, the locking logic is still the same. Can you show me
where the module needs to acquire locks differently than without the
patch?

> 3) Performance will be impacted because of the additional multiplexing in 1)
> and additional resource management in 2).

I thought about this. I concluded it probably isn't measurable and
even if so, it really doesn't matter because domctl hypercalls are
infrequent and never performance-critical.

Mike

-- 
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@xxxxxxxxxx AIM: ncmikeday  Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

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

<Prev in Thread] Current Thread [Next in Thread>