Re: [PATCH for-4.17 3/4] amd/ssbd: remove hypervisor SSBD selection

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Oct 14, 2022 at 11:00:10AM +0200, Jan Beulich wrote:
> On 14.10.2022 10:17, Roger Pau Monné wrote:
> > 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.
> 
> Irrespective of your subsequent reply: Unlike "cpuid=no-ssbd",
> "spec-ctrl=no-ssbd" ought to affect only Xen itself:
> 
> "On hardware supporting SSBD (Speculative Store Bypass Disable), the `ssbd=`
>  option can be used to force or prevent Xen using the feature itself."

So that brings us back to having to context switch SSBD on guest entry
and exit, and we could only do the SSBD switch at context switch if no
ssbd= option is used.

That would also prevent us from dropping the synthetic feature leaf.

I will wait for Andrews opinion on this one, I would like to make sure
we have reached consensus before I send a new version.

Thanks, Roger.