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/
Home Products Support Community News


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

To: Keir Fraser <keir@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM
From: "George S. Coker, II" <gscoker@xxxxxxxxxxxxxx>
Date: Fri, 11 May 2007 13:19:10 -0400
Cc: Derek Murray <Derek.Murray@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 11 May 2007 10:18:05 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C26A5DA4.EC67%keir@xxxxxxxxxxxxx>
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>
References: <C26A5DA4.EC67%keir@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2007-05-11 at 17:51 +0100, Keir Fraser wrote:
> 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.
I guess it's not, my only concern was for the cleanup of set_foreigndom
which is cleaned up as you point out on the error path.

Xen-devel mailing list