On 16.05.2024 21:15, Oleksii K. wrote: > I am not deeply familiar with the technical details surrounding XSM, > but if I understand Daniel's point correctly, the original change > violates the access control framework. This suggests to me that the > revert should be merged. > > However, I have a question: if we merge this revert, does it mean that > using channels a user ( domain ) will be able to get information about > certain events such as EVTCHNSTAT_unbound, EVTCHNSTAT_interdomain, > EVTCHNSTAT_pirq, EVTCHNSTAT_virq, and EVTCHNSTAT_IPI (based on the code > of lseventch.c)? Is this information really so critical that it cannot > be exposed for some time until a patch that changes the XSM policy > consistently is provided and merged? > > If this information is indeed critical and should not be exposed, I > think we can consider Daniel's suggestion to add a check to the dummy > XSM policy as a solution.
The question isn't whether it's critical. As pointed out elsewhere, my view is that any exposure of information needs to come with a proof that nothing undue can be derived from that information. I see Daniel has responded there, so we'll continue the discussion there. Jan
