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
 
   
 

xense-devel

Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM

To: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>, Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Fri, 11 May 2007 17:51:32 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 11 May 2007 09:50:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1178896208.6520.171.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AceT7KCj32f4L//fEdu0qQAX8io7RQ==
Thread-topic: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
User-agent: Microsoft-Entourage/11.3.3.061214


On 11/5/07 16:10, "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx> wrote:

>> The untidiest cases are where set_foreigndom() is involved. These
>> involve do_mmu_update(), do_update_va_otherdomain() and some
>> mmuext_ops. In particular, on the do_update_va_otherdomain() path,
>> IS_PRIV is checked twice. It would seem to me that the cleanest way
>> to do this is to have the permission check first (can domain X access
>> MFN Y of domain Z?), then carry out the set_foreigndom() logic.
>> 
> 
> I think I agree.

In this case you theoretically race reuse of the domid, don't you? Actually
you are saved by the RCU mechanism, but why is doing the check after
set_foreigndom() hard? The error path out of e.g., do_mmu_update() will
correctly give up the foreign reference.

 -- Keir


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