Re: [PATCH] Revert "evtchn: refuse EVTCHNOP_status for Xen-bound event channels"

["Daniel P. Smith" <dpsmith@apertussolutions.com>]

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