Re: [PATCH v3 2/3] x86/vmscape: Replace IBPB with branch history clear on exit to userspace

[Nikolay Borisov <nik.borisov@suse.com>]

On 11/7/25 01:40, Pawan Gupta wrote:
> [ I drafted the reply this this email earlier, but forgot to send it, sorry. ]
> 
> On Mon, Nov 03, 2025 at 12:31:09PM -0800, Dave Hansen wrote:
>> On 10/27/25 16:43, Pawan Gupta wrote:
>>> IBPB mitigation for VMSCAPE is an overkill for CPUs that are only affected
>>> by the BHI variant of VMSCAPE. On such CPUs, eIBRS already provides
>>> indirect branch isolation between guest and host userspace. But, a guest
>>> could still poison the branch history.
>>
>> This is missing a wee bit of background about how branch history and
>> indirect branch prediction are involved in VMSCAPE.
> 
> Adding more background to this.
> 
>>> To mitigate that, use the recently added clear_bhb_long_loop() to isolate
>>> the branch history between guest and userspace. Add cmdline option
>>> 'vmscape=on' that automatically selects the appropriate mitigation based
>>> on the CPU.
>>
>> Is "=on" the right thing here as opposed to "=auto"?
> 
> v1 had it as =auto, David Kaplan made a point that for attack vector controls
> "auto" means "defer to attack vector controls":
> 
>    https://lore.kernel.org/all/LV3PR12MB9265B1C6D9D36408539B68B9941EA@LV3PR12MB9265.namprd12.prod.outlook.com/
> 
>    "Maybe a better solution instead is to add a new option 'vmscape=on'.
> 
>    If we look at the other most recently added bugs like TSA and ITS, neither
>    have an explicit 'auto' cmdline option.  But they do have 'on' cmdline
>    options.
> 
>    The difference between 'auto' and 'on' is that 'auto' defers to the attack
>    vector controls while 'on' means 'enable this mitigation if the CPU is
>    vulnerable' (as opposed to 'force' which will enable it even if not
>    vulnerable).
> 
>    An explicit 'vmscape=on' could give users an option to ensure the
>    mitigation is used (regardless of attack vectors) and could choose the best
>    mitigation (BHB clear if available, otherwise IBPB).

I thought the whole idea of attack vectors was because the gazillion 
options for gazillion mitigation became untenable over time. Now, what 
you are saying is - on top of the simplification, let's add yet more 
options to override the attack vectors o_O. IMO, having 'force' is 
sufficient to cover scenarios where people really want this mitigation - 
either because they know better, or because they want to test something.

Force also covers the "on" case, so let's leave it at "on" for attack 
vector support, and 'force' for everything else

<snip>