File 54be2302-xsm-evtchn-never-pretend-to-have-succe... of Package xen.481

Overview Repositories Revisions Requests Users Attributes Meta

File 54be2302-xsm-evtchn-never-pretend-to-have-successfully-created.patch of Package xen.481

# Commit 09aa4759faa29c1fe735266de4c79f17329bd67b
# Date 2015-01-20 10:42:26 +0100
# Author Andrew Cooper <andrew.cooper3@citrix.com>
# Committer Jan Beulich <jbeulich@suse.com>
xsm/evtchn: never pretend to have successfully created a Xen event channel

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>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>

--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1140,21 +1140,25 @@ int alloc_unbound_xen_event_channel(
 
     spin_lock(&d->event_lock);
 
-    if ( (port = get_free_port(d)) < 0 )
+    rc = get_free_port(d);
+    if ( rc < 0 )
         goto out;
+    port = rc;
     chn = evtchn_from_port(d, port);
 
     rc = xsm_evtchn_unbound(XSM_TARGET, d, chn, remote_domid);
+    if ( rc )
+        goto out;
 
     chn->state = ECS_UNBOUND;
     chn->xen_consumer = get_xen_consumer(notification_fn);
     chn->notify_vcpu_id = local_vcpu->vcpu_id;
-    chn->u.unbound.remote_domid = !rc ? remote_domid : DOMID_INVALID;
+    chn->u.unbound.remote_domid = remote_domid;
 
  out:
     spin_unlock(&d->event_lock);
 
-    return port;
+    return rc < 0 ? rc : port;
 }

Places

File 54be2302-xsm-evtchn-never-pretend-to-have-successfully-created.patch of Package xen.481

Places