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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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.

--
Daniel De Graaf
National Security Agency

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