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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 14.05.2024 11:51, Andrew Cooper wrote:
> On 14/05/2024 10:25 am, Jan Beulich wrote:
>> On 03.04.2024 08: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?
>>>
>>>> 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".
>> You've never responded to this reply of mine, or its follow-up. You also
>> didn't chime in on the discussion Daniel and I were having. I consider my
>> objections unaddressed, and in fact I continue to consider the change to
>> be wrong. Therefore it was inappropriate for you to commit it; it needs
>> reverting asap. If you're not going to do so, I will.
> 
> You tried defending breaking a utility with "well it shouldn't exist then".
> 
> You don't have a leg to stand on, and two maintainers of relevant
> subsystems here just got tired of bullshit being presented in place of
> any credible argument for having done the change in the way you did.

Please can you finally get into the habit of not sending rude replies?

> The correct response was "Sorry I broke things.  Lets revert this for
> now to unbreak, and I'll see about reworking it to not intentionally
> subvert Xen's security mechanism".

I'm sorry, but I didn't break things. I made things more consistent with
the earlier change, as pointed out before: With your revert,
evtchn_status() is now (again) inconsistent with e.g. evtchn_send(). If
you were serious about this being something that needs leaving to XSM,
you'd have adjusted such further uses of consumer_is_xen() as well. But
you aren't. You're merely insisting on lsevtchn needing to continue to
work in a way it should never have worked, with a patch to improve the
situation already pending.

Just to state a very basic principle here again: Xen-internal event
channels ought to either be fully under XSM control when it comes to
domains attempting to access them (in whichever way), or they should
truly be Xen-internal, with access uniformly prevented. To me the
former option simply makes very little sense.

> As it stands, you're 2-1 outvoted, and wasted any sympathy I may have
> had for the principle of the change based on the absurdity of your
> arguments.

No, pending objections are pending objections. Daniel's responses didn't
eliminate them.

As a separate aspect: I can't assume anymore that it is just coincidence
that you taking such a controversial action is at a time when I'm away.

Jan