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

Re: [Xen-devel] [PATCH 08/18] xen: Add DOMID_SELF support to rcu_lock_domain_by_id



On 08/06/2012 11:07 AM, Jan Beulich wrote:
>>>> On 06.08.12 at 16:32, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>> Callers that want to prevent use of DOMID_SELF already need to ensure
>> the calling domain does not pass its own domain ID. This removes the
>> need for the caller to manually support DOMID_SELF, which many already
>> do.
> 
> I'm not really sure this is correct. At the very least it changes the
> return value of rcu_lock_remote_target_domain_by_id() when
> called with DOMID_SELF (from -ESRCH to -EPERM).

This series ends up eliminating that function in patch #18, so that
part is taken care of.
 
> I'm also not convinced that a distinction between a domain knowing
> its ID and one passing DOMID_SELF isn't/can't be useful. That of
> course depends on whether the ID can be fully hidden from a guest
> (obviously pure HVM guests would never know their ID, but then
> again they also would never pass DOMID_SELF anywhere; it might
> be, however, that they could get the latter passed on their behalf
> e.g. from some emulation function).
> 
> Jan

I don't think we can (or want to) make it impossible for a guest to find
out its own domain ID. I agree that the distinction between DOMID_SELF and
my_own_domid can be a useful distinction in some cases. Most of those cases
in Xen that I have seen already handle this at the caller.

Another solution here is to create a function rcu_lock_domain_by_any_id that
is identical to rcu_lock_domain_by_id except for handling DOMID_SELF.

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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