On Thu, Oct 13, 2022 at 04:20:45PM +0200, Jan Beulich wrote:
> On 13.10.2022 15:50, Roger Pau Monné wrote:
> > On Wed, Oct 12, 2022 at 10:30:45AM +0200, Jan Beulich wrote:
> >> On 11.10.2022 18:02, Roger Pau Monne wrote:
> >>> @@ -2365,12 +2365,6 @@ On hardware supporting STIBP (Single Thread
> >>> Indirect Branch Predictors), the
> >>> By default, Xen will use STIBP when IBRS is in use (IBRS implies STIBP),
> >>> and
> >>> when hardware hints recommend using it as a blanket setting.
> >>>
> >>> -On hardware supporting SSBD (Speculative Store Bypass Disable), the
> >>> `ssbd=`
> >>> -option can be used to force or prevent Xen using the feature itself.
> >>
> >> Why would we want to take away this level of control? Shouldn't we turn
> >> this
> >> on while in Xen if so requested? Which would then either mean enabling it
> >> on
> >> VMEXIT if a guest has it off, or running with it turned on using the OR of
> >> guest and host settings.
> >
> > Right, but then we need to context switch the value on vm{entry,exit}
> > which is problematic. I could move the context switch code code out
> > of the GIF=0 region, and assume that NMIs executing with the guest
> > selection of SSBD are OK.
> >
> > Alternatively setting ssbd= on the command line could be taken as a
> > value to enforce for the whole system and prevent guest attempts to
> > change it, not exposing VIRT_SSBD, AMD_SSBD or SSBD (haven't
> > looked at whether not exposing the SSBD CPUID related to
> > SPEC_CTRL.SSBD will have impact on other features).
>
> That would be my preference (albeit I'm uncertain about the "not exposing"
> part, as we don't want to misguide guests into thinking they're unsafe or
> can't guarantee safety when requested by user mode code), but ...
For ssbd=1 we could expose the SSBD controls, as the guest trying to
turn it off would have no effect and it would still be protected.
OTOH if the user sets ssbd=0 on the command line then exposing the
SSBD controls to the guest would be misleading, as the guest setting
SSBD will have no effect and thus it won't be protected when it thinks
it is.
Thanks, Roger.
