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

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

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@xxxxxxxxxx>

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@xxxxxxxxxxxxx>

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®.