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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 21 May 2024, Jan Beulich wrote:
> On 17.05.2024 22:28, Stefano Stabellini wrote:
> > On Fri, 17 May 2024, Jan Beulich wrote:
> >> On 17.05.2024 03:21, Stefano Stabellini wrote:
> >>> On Thu, 16 May 2024, Jan Beulich wrote:
> >>>> 1) In the discussion George claimed that exposing status information in
> >>>> an uncontrolled manner is okay. I'm afraid I have to disagree, seeing
> >>>> how a similar assumption by CPU designers has led to a flood of
> >>>> vulnerabilities over the last 6+ years. Information exposure imo is never
> >>>> okay, unless it can be _proven_ that absolutely nothing "useful" can be
> >>>> inferred from it. (I'm having difficulty seeing how such a proof might
> >>>> look like.)
> >>>
> >>> Many would agree that it is better not to expose status information in
> >>> an uncontrolled manner. Anyway, let's focus on the actionable.
> >>>
> >>>
> >>>> 2) Me pointing out that the XSM hook might similarly get in the way of
> >>>> debugging, Andrew suggested that this is not an issue because any 
> >>>> sensible
> >>>> XSM policy used in such an environment would grant sufficient privilege 
> >>>> to
> >>>> Dom0. Yet that then still doesn't cover why DomU-s also can obtain status
> >>>> for Xen-internal event channels. The debugging argument then becomes 
> >>>> weak,
> >>>> as in that case the XSM hook is possibly going to get in the way.
> >>>>
> >>>> 3) In the discussion Andrew further gave the impression that 
> >>>> evtchn_send()
> >>>> had no XSM check. Yet it has; the difference to evtchn_status() is that
> >>>> the latter uses XSM_TARGET while the former uses XSM_HOOK. (Much like
> >>>> evtchn_status() may indeed be useful for debugging, evtchn_send() may be
> >>>> similarly useful to allow getting a stuck channel unstuck.)
> >>>>
> >>>> In summary I continue to think that an outright revert was inappropriate.
> >>>> DomU-s should continue to be denied status information on Xen-internal
> >>>> event channels, unconditionally and independent of whether dummy, silo, 
> >>>> or
> >>>> Flask is in use.
> >>>
> >>> I think DomU-s should continue to be denied status information on
> >>> Xen-internal event channels *based on the default dummy, silo, or Flask
> >>> policy*. It is not up to us to decide the security policy, only to
> >>> enforce it and provide sensible defaults.
> >>>
> >>> In any case, the XSM_TARGET check in evtchn_status seems to do what we
> >>> want?
> >>
> >> No. XSM_TARGET permits the "owning" (not really, but it's its table) domain
> >> access. See xsm_default_action() in xsm/dummy.h.
> > 
> > Sorry I still don't understand. Why is that a problem? It looks like the
> > wanted default behavior?
> 
> For ordinary event channels - yes. But not for Xen-internal ones, at least
> from my pov.

I understand your point of view, but in my opinion it is OK