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

[Jan Beulich <jbeulich@xxxxxxxx>]

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