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

[Ross Philipson <ross.philipson@xxxxxxxxxx>]

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
> > functionality:
> >
> > http://lists.xen.org/archives/html/xen-devel/2012-11/msg01920.html
> >
> > 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.
> >
> > Thanks,
> > 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).
Thanks,
Ross

Attachment: evtchn_alloc_unbound_split_functions.c
Description: Text Data

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