From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel De Graaf Subject: Re: [PATCH] RFC XSM/evtchn: Never pretend to have successfully created a Xen event channel Date: Mon, 12 Jan 2015 17:12:33 -0500 Message-ID: <54B446D1.4010808@tycho.nsa.gov> References: <1421056983-19328-1-git-send-email-andrew.cooper3@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1421056983-19328-1-git-send-email-andrew.cooper3@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Xen-devel Cc: Ian Jackson , Tim Deegan , Keir Fraser , Ian Campbell , Jan Beulich List-Id: xen-devel@lists.xenproject.org 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 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 -- Daniel De Graaf National Security Agency