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: <ncmike@xxxxxxxxxx>
Subject: [Xen-devel] Re: xsm: Consolidate xsm processing within domain control hypercall.
From: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Date: Tue, 04 Dec 2007 16:54:26 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>
Delivery-date: Tue, 04 Dec 2007 13:54:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071204214635.GB23369@xxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acg2wDyye4ahMqKzEdyuhQAWy5GONg==
Thread-topic: xsm: Consolidate xsm processing within domain control hypercall.
User-agent: Microsoft-Entourage/11.3.6.070618


On 12/4/07 4:46 PM, "Mike D. Day" <ncmike@xxxxxxxxxx> wrote:

> 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.
> 
True, but it makes the security interface incredibly broad.

> 
>> 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?
> 
It's not that the locking logic is different.  A security module may be
sloppy about its locking and cause Xen to crash without specifically
indicating a flaw in the security module.

Getting locks right is tricky business, it would seem the Xen would want the
responsibility for the locking of resources to avoid the ills of race
conditions, etc.

>> 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.
> 
True, this isn't the substantive argument.  I'm concerned about points 1) &
2).

> Mike

-- 
George S. Coker, II <gscoker@xxxxxxxxxxxxxx>



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

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