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

[Jan Beulich <jbeulich@xxxxxxxx>]

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."

Jan