Message-ID: <20251119182622.nkhxgkdpdapeof6o@desk>
Date: Wed, 19 Nov 2025 10:26:42 -0800
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Nikolay Borisov <nik.borisov@...e.com>
Cc: Dave Hansen <dave.hansen@...el.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	David Kaplan <david.kaplan@....com>,
	Sean Christopherson <seanjc@...gle.com>,
	Paolo Bonzini <pbonzini@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Asit Mallick <asit.k.mallick@...el.com>,
	Tao Zhang <tao1.zhang@...el.com>
Subject: Re: [PATCH v3 2/3] x86/vmscape: Replace IBPB with branch history
 clear on exit to userspace

On Wed, Nov 19, 2025 at 12:33:05PM +0200, Nikolay Borisov wrote:
> 
> 
> 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.

Agree with that in general. It all boils down to: Is there are use case
where people would want to use attack vector controls but want to override
one specific mitigation?

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

Force covers the "on" case with a caveat that it also forces the BUG on
unaffected CPUs.

Given that attack vectors do allow all other mitigations to override the
attack vector settings, VMSCAPE should be no different. Or else we
introduce a change to let attack vectors reign all mitigations.

Powered by blists - more mailing lists