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

Re: [Xen-devel] XSM dummy policy blocking event channel creation

On 05/01/2013 03:40 PM, Ross Philipson wrote:
I am working on the next set of V4V patches to post to the list. I have pulled 
the very latest staging branch of Xen and I quickly ran into a new problem. We 
are basically trying to create an event channel during the creation of dom0. We 
have split up the evtchn_alloc_unbound() function into two functions but the 
basic problem is the same. The call to xsm_evtchn_unbound() is returning -EPERM 
from the new code in xsm/dummy.h. This patch set added this functionality:


Specifically we are failing this part of the test return -EPERM:

static always_inline int xsm_default_action(
     xsm_default_t action, struct domain *src, struct domain *target)
     case XSM_TARGET:
         if ( src != target && !IS_PRIV_FOR(src, target) )
             return -EPERM;

The src domain is the current->domain which is idle_domain and target is dom0 
which is in the process of being created. Neither of them is privileged (dom0 is 
not set to privileged yet). And I have not gotten past dom0 creation yet so I 
don't know what will happen when V4V tries to initialize for domU's.

I need some advice on how to proceed here. I am not terribly conversant in the 
working of XSM and do not have a clear idea how to proceed.

Ross Philipson

The answer for domUs is actually easier: the domain builder (dom0) will
satisfy IS_PRIV_FOR(dom0, newdomU) and so the creation will be allowed.
With FLASK, the remote domain will also be considered, so I presume you
have set something valid there (it needs to have a struct domain* that
rcu_lock_domain_by_any_id can be used to fetch).

Event channels created by the hypervisor are normally allocated using
alloc_unbound_xen_event_channel instead of evtchn_alloc_unbound; the
former will not fail the creation of the event channel if the XSM hook
denies, but will instead change the remote domain ID to DOMID_INVALID.
Depending on what you intend the remote domid to be in this newly
allocated event channel, this may or may not be useful behavior; the
semantics of alloc_unbound_xen_event_channel are also different, so
you would need to change your calling code with this in mind.

If you want to use evtchn_alloc_unbound directly, you probably need to
add logic to omit the XSM check during the creation of dom0 - and this
likely belongs in the evtchn_alloc_unbound function rather than the
dummy XSM hook.  The XSM changes you referenced don't actually introduce
this, since before the call to rcu_lock_target_domain_by_id would have
failed because the idle domain does not satisfy IS_PRIV_FOR on dom0.

Daniel De Graaf
National Security Agency

Xen-devel mailing list



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