[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.