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
