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 18:26:37 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Alex Williamson <alex.williamson@xxxxxx>
Delivery-date: Tue, 04 Dec 2007 15:26:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071204215902.GD23369@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: Acg2zR1tXCs1LKLAEdyuhQAWy5GONg==
Thread-topic: xsm: Consolidate xsm processing within domain control hypercall.
User-agent: Microsoft-Entourage/11.3.6.070618
On 12/4/07 4:59 PM, "Mike D. Day" <ncmike@xxxxxxxxxx> wrote:

> On 04/12/07 16:54 -0500, George S. Coker, II wrote:
>> 
>>> 
>>>> 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.
> 
> I agree with your comments, but I don't think the patch changes
> locking at all. If I'm wrong I agree that's a problem.

I guess I'm not quite following here.  True the locking mechanisms won't be
any different.  The same resources will be locked, hopefully, and released,
hopefully.  The issue is one of interfaces, and which parts of Xen have
responsibility for resource management and which parts are responsible for
security.  Having a clean delegation of responsibility is good for core xen
developers and xen security developers.

-- 
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>