From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [Xense-devel][PATCH][1/4] Xen Security Modules: XSM Date: Fri, 11 May 2007 17:51:32 +0100 Message-ID: References: <1178896208.6520.171.camel@moss-walleye.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1178896208.6520.171.camel@moss-walleye.epoch.ncsc.mil> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "George S. Coker, II" , Derek Murray Cc: xen-devel@lists.xensource.com, Keir Fraser , xense-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 11/5/07 16:10, "George S. Coker, II" 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