[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 04:50 PM, Daniel De Graaf wrote:
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


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)
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

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.

Thank you for getting back to me so quickly.

Perhaps I should share the new split up evtchn_alloc* functions since the way they are done is relevant to your answer. I attached a snippet with the split functions. We are directly calling evtchn_alloc_unbound_domain() which does not call rcu_lock_domain_by_any_id(). So the permissions block is related only to the changes in dummy.c I believe.

I am still digging through the history of the posts and responses to see how they settled on that configuration of the evtchn_alloc* functions but this might explain things for you a bit better (e.g. why it worked prior to the dummy.c changes).


Attachment: evtchn_alloc_unbound_split_functions.c
Description: Text Data

Xen-devel mailing list



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