Re: [PATCH] RFC XSM/evtchn: Never pretend to have successfully created a Xen event channel

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 01/12/2015 05:03 AM, Andrew Cooper wrote:
> This is RFC because explicitly changes the logic introduced by c/s b34f2c375
> "xsm: label xen-consumer event channels", and is only compile tested.
>
> Xen event channels are not internal resources.  They still have one end in a
> domain, and are created at the request of privileged domains.  This logic
> which "successfully" creates a Xen event channel opens up undesirable failure
> cases with ill-specified XSM policies.
>
> If a domain is permitted to create ioreq servers or memevent listeners, but
> not to create event channels, the ioreq/memevent creation will succeed but
> attempting to bind the returned event channel will fail without any indication
> of a permission error.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

This feature was originally required in order to support HVM domains which
are created by a (non-dom0) toolstack domain which does not itself provide
any services to the HVM domain.  During creation, the domain would create
the ioreq event channels to the toolstack, which was not permitted by the
XSM policy; masking this error allowed the channels to be created and then
replaced (correctly) when the device model domain was set.

 From my current inspection, this workaround may no longer be needed.  In
any case, I think it is better to expose the error and force the caller
to explicitly request a dummy event channel (or just postpone creation).

Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

-- 
Daniel De Graaf
National Security Agency