[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<LV3PR12MB9265B1C6D9D36408539B68B9941EA@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Fri, 26 Sep 2025 13:39:37 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: "x86@...nel.org" <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Josh
Poimboeuf <jpoimboe@...nel.org>, Sean Christopherson <seanjc@...gle.com>,
Paolo Bonzini <pbonzini@...hat.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
Asit Mallick <asit.k.mallick@...el.com>, Tao Zhang <tao1.zhang@...el.com>
Subject: RE: [PATCH 2/2] x86/vmscape: Replace IBPB with branch history clear
on exit to userspace
[AMD Official Use Only - AMD Internal Distribution Only]
> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> Sent: Thursday, September 25, 2025 5:03 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: x86@...nel.org; H. Peter Anvin <hpa@...or.com>; Josh Poimboeuf
> <jpoimboe@...nel.org>; Sean Christopherson <seanjc@...gle.com>; Paolo
> Bonzini <pbonzini@...hat.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 2/2] x86/vmscape: Replace IBPB with branch history clear on
> exit to userspace
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Sep 25, 2025 at 06:14:54PM +0000, Kaplan, David wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > > -----Original Message-----
> > > From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> > > Sent: Wednesday, September 24, 2025 10:10 PM
> > > To: x86@...nel.org; H. Peter Anvin <hpa@...or.com>; Josh Poimboeuf
> > > <jpoimboe@...nel.org>; Kaplan, David <David.Kaplan@....com>; Sean
> > > Christopherson <seanjc@...gle.com>; Paolo Bonzini <pbonzini@...hat.com>
> > > Cc: linux-kernel@...r.kernel.org; kvm@...r.kernel.org; Asit Mallick
> > > <asit.k.mallick@...el.com>; Tao Zhang <tao1.zhang@...el.com>
> > > Subject: [PATCH 2/2] x86/vmscape: Replace IBPB with branch history clear on
> exit
> > > to userspace
> > >
> > > Caution: This message originated from an External Source. Use proper caution
> > > when opening attachments, clicking links, or responding.
> > >
> > >
> > > 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.
> > >
> > > To mitigate that, use the recently added clear_bhb_long_loop() to isolate
> > > the branch history between guest and userspace. Add cmdline option
> > > 'vmscape=auto' that automatically selects the appropriate mitigation based
> > > on the CPU.
> > >
> > > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> > > ---
> > > Documentation/admin-guide/hw-vuln/vmscape.rst | 8 +++++
> > > Documentation/admin-guide/kernel-parameters.txt | 4 ++-
> > > arch/x86/include/asm/cpufeatures.h | 1 +
> > > arch/x86/include/asm/entry-common.h | 12 ++++---
> > > arch/x86/include/asm/nospec-branch.h | 2 +-
> > > arch/x86/kernel/cpu/bugs.c | 44 ++++++++++++++++++-------
> > > arch/x86/kvm/x86.c | 5 +--
> > > 7 files changed, 55 insertions(+), 21 deletions(-)
> > >
> > > diff --git a/Documentation/admin-guide/hw-vuln/vmscape.rst
> > > b/Documentation/admin-guide/hw-vuln/vmscape.rst
> > > index
> > >
> d9b9a2b6c114c05a7325e5f3c9d42129339b870b..13ca98f952f97daeb28194c3873e
> > > 945b85eda6a1 100644
> > > --- a/Documentation/admin-guide/hw-vuln/vmscape.rst
> > > +++ b/Documentation/admin-guide/hw-vuln/vmscape.rst
> > > @@ -86,6 +86,10 @@ The possible values in this file are:
> > > run a potentially malicious guest and issues an IBPB before the first
> > > exit to userspace after VM-exit.
> > >
> > > + * 'Mitigation: Clear BHB before exit to userspace':
> > > +
> > > + As above conditional BHB clearing mitigation is enabled.
> > > +
> > > * 'Mitigation: IBPB on VMEXIT':
> > >
> > > IBPB is issued on every VM-exit. This occurs when other mitigations like
> > > @@ -108,3 +112,7 @@ The mitigation can be controlled via the ``vmscape=``
> > > command line parameter:
> > >
> > > Force vulnerability detection and mitigation even on processors that are
> > > not known to be affected.
> > > +
> > > + * ``vmscape=auto``:
> > > +
> > > + Choose the mitigation based on the VMSCAPE variant the CPU is affected
> by.
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > > b/Documentation/admin-guide/kernel-parameters.txt
> > > index
> > >
> 5a7a83c411e9c526f8df6d28beb4c784aec3cac9..4596bfcb401f1a89d2dc5ed8c44c8
> > > 3628c9c5dfe 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -8048,9 +8048,11 @@
> > >
> > > off - disable the mitigation
> > > ibpb - use Indirect Branch Prediction Barrier
> > > - (IBPB) mitigation (default)
> > > + (IBPB) mitigation
> > > force - force vulnerability detection even on
> > > unaffected processors
> > > + auto - (default) automatically select IBPB
> > > + or BHB clear mitigation based on CPU
> >
> > Many of the other bugs (like srso, l1tf, bhi, etc.) do not have explicit
> > 'auto' options as 'auto' is implied by the lack of an explicit option.
> > Is there really value in creating an explicit 'auto' option here?
>
> Hmm, so to get the BHB clear mitigation do we advise the users to remove
> the vmscape= parameter? That feels a bit weird to me. Also, with
> CONFIG_MITIGATION_VMSCAPE=n a user can get IBPB mitigation with
> vmscape=ibpb, but there is not way to get the BHB clear mitigation.
>
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'd still advise users to not specify any option here unless they know what they're doing. But an 'on' option would arguably be more consistent with the other recent bugs and maybe meets the needs you're after?
--David Kaplan
Powered by blists - more mailing lists