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

Re: [Xen-devel] [PATCH 09/11] evtchn: implement EVTCHNOP_set_limit

On 09/13/2013 12:56 PM, David Vrabel wrote:
From: David Vrabel <david.vrabel@xxxxxxxxxx>

Add max_evtchn_port to struct domain as the maximum port number that a
domain may bind.  Allow a suitably privileged domain to set this limit
so it may restrict the other domain's usage of Xen resources for event
channels (primarily global mapping entries for the shared data

The default values for this limit is unlimited for control domains or
NR_EVENT_CHANNELS - 1 for other domains.  These defaults ensure that no
domain will regress in the number of event channels they may use.

If a domain is expected to use the FIFO-based event channel ABI, a
toolstack may wish to set the limit to 1023 or lower to ensure a
minimum number of global mapping entries is used.

Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
Cc: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>

This allows device model domains to adjust the limit of their target
domain arbitrarily; I think it makes more sense for this to be XSM_PRIV
so that only dom0 can adjust it, similar to max_mem. Control domains
will already need an explicit XSM policy that can address this as a
fine-grained permission.

The new XSM hook also needs to be added to xsm/dummy.c. Adding a FLASK
hook and permission similar to the one for evtchn_reset would also be
nice, but that may fit better in a later patch that adds this operation
to the example security policy.

With the check changed to XSM_PRIV and a set_to_dummy_if_null line added
to xsm/dummy.c, 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®.