The commit makes a claim without any kind of justification.

The claim is false, and the commit broke lsevtchn in dom0.  It is also quite
obvious from XSM_TARGET that it has broken device model stubdoms too.

Whether to return information about a xen-owned evtchn is a matter of policy,
and it's not acceptable to short circuit the XSM on the matter.

This reverts commit f60ab5337f968e2f10c639ab59db7afb0fe4f7c3.

Fixes: f60ab5337f96 ("evtchn: refuse EVTCHNOP_status for Xen-bound event channels")
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
CC: George Dunlap <George.Dunlap@citrix.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien@xen.org>
CC: Daniel Smith <dpsmith@apertussolutions.com>
---
 xen/common/event_channel.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 20f586cf5ecd..ae6c2f902645 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1040,12 +1040,6 @@ int evtchn_status(evtchn_status_t *status)
 
     read_lock(&d->event_lock);
 
-    if ( consumer_is_xen(chn) )
-    {
-        rc = -EACCES;
-        goto out;
-    }
-
     rc = xsm_evtchn_status(XSM_TARGET, d, chn);
     if ( rc )
         goto out;

base-commit: 7a09966e7b2823b70f6d56d0cf66c11124f4a3c1
-- 
2.30.2

On 4/2/24 13:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.
> 
> The claim is false, and the commit broke lsevtchn in dom0.  It is also quite
> obvious from XSM_TARGET that it has broken device model stubdoms too.
> 
> Whether to return information about a xen-owned evtchn is a matter of policy,
> and it's not acceptable to short circuit the XSM on the matter.
> 
> This reverts commit f60ab5337f968e2f10c639ab59db7afb0fe4f7c3.
> 
> Fixes: f60ab5337f96 ("evtchn: refuse EVTCHNOP_status for Xen-bound event channels")
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: George Dunlap <George.Dunlap@citrix.com>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Stefano Stabellini <sstabellini@kernel.org>
> CC: Julien Grall <julien@xen.org>
> CC: Daniel Smith <dpsmith@apertussolutions.com>
> ---
>   xen/common/event_channel.c | 6 ------
>   1 file changed, 6 deletions(-)
> 
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index 20f586cf5ecd..ae6c2f902645 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1040,12 +1040,6 @@ int evtchn_status(evtchn_status_t *status)
>   
>       read_lock(&d->event_lock);
>   
> -    if ( consumer_is_xen(chn) )
> -    {
> -        rc = -EACCES;
> -        goto out;
> -    }
> -
>       rc = xsm_evtchn_status(XSM_TARGET, d, chn);
>       if ( rc )
>           goto out;
> 
> base-commit: 7a09966e7b2823b70f6d56d0cf66c11124f4a3c1

Acked-by: Daniel P. Smith <dpsmith@apertussolutions.com>

On 02.04.2024 19:06, Andrew Cooper wrote:
> The commit makes a claim without any kind of justification.

Well, what does "have no business" leave open?

> The claim is false, and the commit broke lsevtchn in dom0.

Or alternatively lsevtchn was doing something that was never meant to work
(from Xen's perspective).

>  It is also quite
> obvious from XSM_TARGET that it has broken device model stubdoms too.

Why would that be "obvious"? What business would a stubdom have to look at
Xen's side of an evtchn?

> Whether to return information about a xen-owned evtchn is a matter of policy,
> and it's not acceptable to short circuit the XSM on the matter.

I can certainly accept this as one possible view point. As in so many cases
I'm afraid I dislike you putting it as if it was the only possible one.

In summary: The supposed justification you claim is missing in the original
change is imo also missing here then: What business would any entity in the
system have to look at Xen's side of an event channel? Back at the time, 3
people agreed that it's "none".

Jan

On 4/3/24 02:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> The commit makes a claim without any kind of justification.
> 
> Well, what does "have no business" leave open?

Why does it not have any business? Why should a domain that creates an 
event channel not be able to inquire about its status?

>> The claim is false, and the commit broke lsevtchn in dom0.
> 
> Or alternatively lsevtchn was doing something that was never meant to work
> (from Xen's perspective).

Again, you have not said why this is a problem. What concern does it 
create? Does it open the door for access elevation, resource 
deprivation, or some other malicious behaviors?

>>   It is also quite
>> obvious from XSM_TARGET that it has broken device model stubdoms too.
> 
> Why would that be "obvious"? What business would a stubdom have to look at
> Xen's side of an evtchn?

Again, you have not expressed why it shouldn't be able to do so.

>> Whether to return information about a xen-owned evtchn is a matter of policy,
>> and it's not acceptable to short circuit the XSM on the matter.
> 
> I can certainly accept this as one possible view point. As in so many cases
> I'm afraid I dislike you putting it as if it was the only possible one.

In fact, this commit is in violation of the XSM. It hard-codes a 
resource access check outside XSM, thus breaking the fine-grained access 
control of FLASK.

> In summary: The supposed justification you claim is missing in the original
> change is imo also missing here then: What business would any entity in the
> system have to look at Xen's side of an event channel? Back at the time, 3
> people agreed that it's "none".

As stated, you provided no reason or justification for "has no business" 
and by face value is an opinion that a few people agreed with. As for 
why, there could be a myriad number of reasons a domain may want to 
check the status of an interface it has with the hypervisor. From just 
logging its state for debug to throttling attempts at sending an event. 
So why, from a security/access control decision, does this access have 
to absolutely blocked, even from FLASK?

v/r,
dps

On 03.04.2024 13:10, Daniel P. Smith wrote:
> On 4/3/24 02:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>>
>> Well, what does "have no business" leave open?
> 
> Why does it not have any business? Why should a domain that creates an 
> event channel not be able to inquire about its status?

Event channels we talk about here are created via
alloc_unbound_xen_event_channel(). IOW it's not any domain creating them.
Once connected, the respective domain is of course fine to query its end
of the channel.

>>> The claim is false, and the commit broke lsevtchn in dom0.
>>
>> Or alternatively lsevtchn was doing something that was never meant to work
>> (from Xen's perspective).
> 
> Again, you have not said why this is a problem. What concern does it 
> create? Does it open the door for access elevation, resource 
> deprivation, or some other malicious behaviors?

It exposes information that perhaps better wouldn't be exposed. Imo if
Xen owned resource state is of interest, it would want exposing via
hypfs.

>>>   It is also quite
>>> obvious from XSM_TARGET that it has broken device model stubdoms too.
>>
>> Why would that be "obvious"? What business would a stubdom have to look at
>> Xen's side of an evtchn?
> 
> Again, you have not expressed why it shouldn't be able to do so.

See above - not its resource, nor its guest's.

>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>> and it's not acceptable to short circuit the XSM on the matter.
>>
>> I can certainly accept this as one possible view point. As in so many cases
>> I'm afraid I dislike you putting it as if it was the only possible one.
> 
> In fact, this commit is in violation of the XSM. It hard-codes a 
> resource access check outside XSM, thus breaking the fine-grained access 
> control of FLASK.

Perhaps; see below and see the question raised in the subsequent reply
to the patch.

>> In summary: The supposed justification you claim is missing in the original
>> change is imo also missing here then: What business would any entity in the
>> system have to look at Xen's side of an event channel? Back at the time, 3
>> people agreed that it's "none".
> 
> As stated, you provided no reason or justification for "has no business" 
> and by face value is an opinion that a few people agreed with. As for 
> why, there could be a myriad number of reasons a domain may want to 
> check the status of an interface it has with the hypervisor. From just 
> logging its state for debug to throttling attempts at sending an event. 
> So why, from a security/access control decision, does this access have 
> to absolutely blocked, even from FLASK?

I didn't say it absolutely needs to be blocked. I'm okay to become
convinced otherwise. But in the description complaining about lack of
reasons in the 3-4 year old change, just to then again not provide any
reasons looks "interesting" to me. (And no, just to take that example,
lsevtchn not working anymore on such channels is not on its own a
reason. As indicated, it may well be that conceptually it was never
supposed to be able to have access to this information. The latest not
anymore when hypfs was introduced.)

Jan

On 4/3/24 08:05, Jan Beulich wrote:
> On 03.04.2024 13:10, Daniel P. Smith wrote:
>> On 4/3/24 02:16, Jan Beulich wrote:
>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>> The commit makes a claim without any kind of justification.
>>>
>>> Well, what does "have no business" leave open?
>>
>> Why does it not have any business? Why should a domain that creates an
>> event channel not be able to inquire about its status?
> 
> Event channels we talk about here are created via
> alloc_unbound_xen_event_channel(). IOW it's not any domain creating them.
> Once connected, the respective domain is of course fine to query its end
> of the channel.


I would disagree, for instance alloc_unbound_xen_event_channel() is used 
in response to XEN_DOMCTL_vuart_op:XEN_DOMCTL_VUART_OP_INIT and 
XEN_DOMCTL_VM_EVENT_OP_PAGING:XEN_VM_EVENT_ENABLE, which are hypercalls 
by a domain and not something initiated by the hypervisor.

>>>> The claim is false, and the commit broke lsevtchn in dom0.
>>>
>>> Or alternatively lsevtchn was doing something that was never meant to work
>>> (from Xen's perspective).
>>
>> Again, you have not said why this is a problem. What concern does it
>> create? Does it open the door for access elevation, resource
>> deprivation, or some other malicious behaviors?
> 
> It exposes information that perhaps better wouldn't be exposed. Imo if
> Xen owned resource state is of interest, it would want exposing via
> hypfs.

You didn't answer why, just again expressed your opinion that it is not 
better exposed. And I would have to wholly disagree with the sentiment 
that hypfs exposure is the deciding factor what is or is not worth 
exposing. This thinking is completely orthogonal to FLASK and 
fine-grained access control.

>>>>    It is also quite
>>>> obvious from XSM_TARGET that it has broken device model stubdoms too.
>>>
>>> Why would that be "obvious"? What business would a stubdom have to look at
>>> Xen's side of an evtchn?
>>
>> Again, you have not expressed why it shouldn't be able to do so.
> 
> See above - not its resource, nor its guest's.

It is a resource provided to a domain that the domain can send/raise an 
event to and a backing domain that can bind to it, ie. the two 
parameters that must be passed to the allocation call.

>>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>>> and it's not acceptable to short circuit the XSM on the matter.
>>>
>>> I can certainly accept this as one possible view point. As in so many cases
>>> I'm afraid I dislike you putting it as if it was the only possible one.
>>
>> In fact, this commit is in violation of the XSM. It hard-codes a
>> resource access check outside XSM, thus breaking the fine-grained access
>> control of FLASK.
> 
> Perhaps; see below and see the question raised in the subsequent reply
> to the patch.
> 
>>> In summary: The supposed justification you claim is missing in the original
>>> change is imo also missing here then: What business would any entity in the
>>> system have to look at Xen's side of an event channel? Back at the time, 3
>>> people agreed that it's "none".
>>
>> As stated, you provided no reason or justification for "has no business"
>> and by face value is an opinion that a few people agreed with. As for
>> why, there could be a myriad number of reasons a domain may want to
>> check the status of an interface it has with the hypervisor. From just
>> logging its state for debug to throttling attempts at sending an event.
>> So why, from a security/access control decision, does this access have
>> to absolutely blocked, even from FLASK?
> 
> I didn't say it absolutely needs to be blocked. I'm okay to become
> convinced otherwise. But in the description complaining about lack of
> reasons in the 3-4 year old change, just to then again not provide any
> reasons looks "interesting" to me. (And no, just to take that example,
> lsevtchn not working anymore on such channels is not on its own a
> reason. As indicated, it may well be that conceptually it was never
> supposed to be able to have access to this information. The latest not
> anymore when hypfs was introduced.)

This broke an existing behavior, whether that behavior is correct can 
always be questioned, does not justify leaving an incorrect 
implementation. And it is incorrect because as again you have not 
articulated why the lsevtchn behavior is wrong and thus whether this is 
the valid corrective action.

v/r,
dps

On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
>>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>>>    It is also quite
>>>>> obvious from XSM_TARGET that it has broken device model stubdoms too.
>>>>
>>>> Why would that be "obvious"? What business would a stubdom have to look at
>>>> Xen's side of an evtchn?
>>>
>>> Again, you have not expressed why it shouldn't be able to do so.
>>
>> See above - not its resource, nor its guest's.
> 
> It is a resource provided to a domain that the domain can send/raise an 
> event to and a backing domain that can bind to it, ie. the two 
> parameters that must be passed to the allocation call.

Before writing this particular part of your reply, did you look as
evtchn_send()? Sending on such ports is similarly denied without
involving XSM. For a good reason, stated in the accompanying comment.
It is therefore simply inconsistent to allow any kind of other
operation on such ports. Hence the patch that Andrew now deems needs
reverting.

In fact I view these ports living in the guest's event channel space
as similarly inappropriate as the ioreq pages - until a few years
back - living in the guest's GFN space.

Jan

On 03.04.2024 15:27, Daniel P. Smith wrote:
> On 4/3/24 08:05, Jan Beulich wrote:
>> On 03.04.2024 13:10, Daniel P. Smith wrote:
>>> On 4/3/24 02:16, Jan Beulich wrote:
>>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>>> The commit makes a claim without any kind of justification.
>>>>
>>>> Well, what does "have no business" leave open?
>>>
>>> Why does it not have any business? Why should a domain that creates an
>>> event channel not be able to inquire about its status?
>>
>> Event channels we talk about here are created via
>> alloc_unbound_xen_event_channel(). IOW it's not any domain creating them.
>> Once connected, the respective domain is of course fine to query its end
>> of the channel.
> 
> I would disagree, for instance alloc_unbound_xen_event_channel() is used 
> in response to XEN_DOMCTL_vuart_op:XEN_DOMCTL_VUART_OP_INIT and 
> XEN_DOMCTL_VM_EVENT_OP_PAGING:XEN_VM_EVENT_ENABLE, which are hypercalls 
> by a domain and not something initiated by the hypervisor.

Those ports, aiui, aren't supposed to be used by the caller for other
than connecting an inter-domain port to the other side.

>>>>> The claim is false, and the commit broke lsevtchn in dom0.
>>>>
>>>> Or alternatively lsevtchn was doing something that was never meant to work
>>>> (from Xen's perspective).
>>>
>>> Again, you have not said why this is a problem. What concern does it
>>> create? Does it open the door for access elevation, resource
>>> deprivation, or some other malicious behaviors?
>>
>> It exposes information that perhaps better wouldn't be exposed. Imo if
>> Xen owned resource state is of interest, it would want exposing via
>> hypfs.
> 
> You didn't answer why, just again expressed your opinion that it is not 
> better exposed.

I'm sorry, but "better wouldn't be exposed" includes the "why" part
already imo: Information should simply not be exposed unduly. For
every bit of exposed information, there ought to be a reason (and
then the right vehicle used for exposure).

>>>>>    It is also quite
>>>>> obvious from XSM_TARGET that it has broken device model stubdoms too.
>>>>
>>>> Why would that be "obvious"? What business would a stubdom have to look at
>>>> Xen's side of an evtchn?
>>>
>>> Again, you have not expressed why it shouldn't be able to do so.
>>
>> See above - not its resource, nor its guest's.
> 
> It is a resource provided to a domain that the domain can send/raise an 
> event to and a backing domain that can bind to it, ie. the two 
> parameters that must be passed to the allocation call.

I don't think so: As per above (my understanding may be wrong), it's only
the other side of the connection which is available for use by a domain.
Over night I was pretty close to admitting a mistake there, but upon re-
checking of the sources I could only find this view of mine supported.
Which doesn't mean I'm viewing things correctly; please point out my
mistake if there is any.

>>>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>>>> and it's not acceptable to short circuit the XSM on the matter.
>>>>
>>>> I can certainly accept this as one possible view point. As in so many cases
>>>> I'm afraid I dislike you putting it as if it was the only possible one.
>>>
>>> In fact, this commit is in violation of the XSM. It hard-codes a
>>> resource access check outside XSM, thus breaking the fine-grained access
>>> control of FLASK.
>>
>> Perhaps; see below and see the question raised in the subsequent reply
>> to the patch.
>>
>>>> In summary: The supposed justification you claim is missing in the original
>>>> change is imo also missing here then: What business would any entity in the
>>>> system have to look at Xen's side of an event channel? Back at the time, 3
>>>> people agreed that it's "none".
>>>
>>> As stated, you provided no reason or justification for "has no business"
>>> and by face value is an opinion that a few people agreed with. As for
>>> why, there could be a myriad number of reasons a domain may want to
>>> check the status of an interface it has with the hypervisor. From just
>>> logging its state for debug to throttling attempts at sending an event.
>>> So why, from a security/access control decision, does this access have
>>> to absolutely blocked, even from FLASK?
>>
>> I didn't say it absolutely needs to be blocked. I'm okay to become
>> convinced otherwise. But in the description complaining about lack of
>> reasons in the 3-4 year old change, just to then again not provide any
>> reasons looks "interesting" to me. (And no, just to take that example,
>> lsevtchn not working anymore on such channels is not on its own a
>> reason. As indicated, it may well be that conceptually it was never
>> supposed to be able to have access to this information. The latest not
>> anymore when hypfs was introduced.)
> 
> This broke an existing behavior, whether that behavior is correct can 
> always be questioned, does not justify leaving an incorrect 
> implementation. And it is incorrect because as again you have not 
> articulated why the lsevtchn behavior is wrong and thus whether this is 
> the valid corrective action.

Again - if lsevtchn is supposed to be able to access Xen-internal
resources, _that_ is what needs justifying. Otherwise my take is that
it is supposed to only access domain resources.

Jan

On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> Whether to return information about a xen-owned evtchn is a matter of policy,
>> and it's not acceptable to short circuit the XSM on the matter.
> 
> I can certainly accept this as one possible view point. As in so many cases
> I'm afraid I dislike you putting it as if it was the only possible one.

Further to this: Is there even a way to express the same denial in XSM?
alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
channel, and (yes, it could in principle be open-coded in Flask code)
consumer_is_xen() is private to event_channel.c. I also dare to question
whether in SILO mode status information like this should be available.

Jan

On 4/3/24 02:52, Jan Beulich wrote:
> On 03.04.2024 08:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>> and it's not acceptable to short circuit the XSM on the matter.
>>
>> I can certainly accept this as one possible view point. As in so many cases
>> I'm afraid I dislike you putting it as if it was the only possible one.
> 
> Further to this: Is there even a way to express the same denial in XSM?
> alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
> channel, and (yes, it could in principle be open-coded in Flask code)
> consumer_is_xen() is private to event_channel.c. I also dare to question
> whether in SILO mode status information like this should be available.

To build on the previous response: if the natural failure return value 
is -EACCESS in response to a domain resource access attempt, then the 
probability is extremely high that it should be implemented under a XSM 
hook and not hard-coded into the resource logic.

v/r,
dps

On 03.04.2024 13:50, Daniel P. Smith wrote:
> On 4/3/24 02:52, Jan Beulich wrote:
>> On 03.04.2024 08:16, Jan Beulich wrote:
>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>>> and it's not acceptable to short circuit the XSM on the matter.
>>>
>>> I can certainly accept this as one possible view point. As in so many cases
>>> I'm afraid I dislike you putting it as if it was the only possible one.
>>
>> Further to this: Is there even a way to express the same denial in XSM?
>> alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
>> channel, and (yes, it could in principle be open-coded in Flask code)
>> consumer_is_xen() is private to event_channel.c. I also dare to question
>> whether in SILO mode status information like this should be available.
> 
> To build on the previous response: if the natural failure return value 
> is -EACCESS in response to a domain resource access attempt, then the 
> probability is extremely high that it should be implemented under a XSM 
> hook and not hard-coded into the resource logic.

Possibly. But first of all - could you answer the earlier question I raised?

Jan

On 4/3/24 07:54, Jan Beulich wrote:
> On 03.04.2024 13:50, Daniel P. Smith wrote:
>> On 4/3/24 02:52, Jan Beulich wrote:
>>> On 03.04.2024 08:16, Jan Beulich wrote:
>>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>>>> and it's not acceptable to short circuit the XSM on the matter.
>>>>
>>>> I can certainly accept this as one possible view point. As in so many cases
>>>> I'm afraid I dislike you putting it as if it was the only possible one.
>>>
>>> Further to this: Is there even a way to express the same denial in XSM?
>>> alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
>>> channel, and (yes, it could in principle be open-coded in Flask code)
>>> consumer_is_xen() is private to event_channel.c. I also dare to question
>>> whether in SILO mode status information like this should be available.
>>
>> To build on the previous response: if the natural failure return value
>> is -EACCESS in response to a domain resource access attempt, then the
>> probability is extremely high that it should be implemented under a XSM
>> hook and not hard-coded into the resource logic.
> 
> Possibly. But first of all - could you answer the earlier question I raised?

Don't need to, this change subverts/violates the access control 
framework. If the desire is to make this access decision for the 
default/dummy policy, then codify it there. Otherwise I will be ack'ing 
this change since it is access control and falls under the purview of XSM.

v/r,
dps

On 03.04.2024 15:31, Daniel P. Smith wrote:
> On 4/3/24 07:54, Jan Beulich wrote:
>> On 03.04.2024 13:50, Daniel P. Smith wrote:
>>> On 4/3/24 02:52, Jan Beulich wrote:
>>>> On 03.04.2024 08:16, Jan Beulich wrote:
>>>>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>>>>> Whether to return information about a xen-owned evtchn is a matter of policy,
>>>>>> and it's not acceptable to short circuit the XSM on the matter.
>>>>>
>>>>> I can certainly accept this as one possible view point. As in so many cases
>>>>> I'm afraid I dislike you putting it as if it was the only possible one.
>>>>
>>>> Further to this: Is there even a way to express the same denial in XSM?
>>>> alloc_unbound_xen_event_channel() doesn't specifically "mark" such a
>>>> channel, and (yes, it could in principle be open-coded in Flask code)
>>>> consumer_is_xen() is private to event_channel.c. I also dare to question
>>>> whether in SILO mode status information like this should be available.
>>>
>>> To build on the previous response: if the natural failure return value
>>> is -EACCESS in response to a domain resource access attempt, then the
>>> probability is extremely high that it should be implemented under a XSM
>>> hook and not hard-coded into the resource logic.
>>
>> Possibly. But first of all - could you answer the earlier question I raised?
> 
> Don't need to, this change subverts/violates the access control 
> framework. If the desire is to make this access decision for the 
> default/dummy policy, then codify it there. Otherwise I will be ack'ing 
> this change since it is access control and falls under the purview of XSM.

If Xen internals like this are to be exposable (and controlled by XSM), why
would other Xen internals not similarly be (optionally) exposed?

Further, since above you referred to EACCES being what XSM is supposed to
control: xsm_default_action() used EPERM, and (presumably; too long ago)
EACCES was chosen here precisely to make it not look like an XSM surrogate.

Jan