linux-kernel - Re: [PATCH] x86/bhi: avoid hardware mitigation for 'spectre

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CALMp9eRvoY5NH3sW6tc+=mP=7ZtuC05HQJUrZdvDAdt27B2cZw@mail.gmail.com>
Date: Fri, 13 Sep 2024 19:35:08 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc: Chao Gao <chao.gao@...el.com>, Jon Kohler <jon@...anix.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Ingo Molnar <mingo@...hat.com>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, X86 ML <x86@...nel.org>, 
	"H. Peter Anvin" <hpa@...or.com>, LKML <linux-kernel@...r.kernel.org>, 
	"kvm @ vger . kernel . org" <kvm@...r.kernel.org>
Subject: Re: [PATCH] x86/bhi: avoid hardware mitigation for 'spectre_bhi=vmexit'

On Fri, Sep 13, 2024 at 5:16 PM Pawan Gupta
<pawan.kumar.gupta@...ux.intel.com> wrote:
>
> On Fri, Sep 13, 2024 at 04:04:56PM -0700, Jim Mattson wrote:
> > > The IA32_SPEC_CTRL mask and shadow fields should be perfect for this.
> >
> > In fact, this is the guidance given in
> > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html:
> >
> > The VMM should use the “virtualize IA32_SPEC_CTRL” VM-execution
> > control to cause BHI_DIS_S to be set (see the VMM Support for
> > BHB-clearing Software Sequences section) whenever:
> > o The VMM is running on a processor for which the short software
> > sequence may not be effective:
> >   - Specifically, it does not enumerate BHI_NO, but does enumerate
> > BHI_DIS_S, and is not an Atom-only processor.
> >
> > In other words, the VMM should set bit 10 in the IA32_SPEC_CTRL mask
> > on SPR. As long as the *effective* guest IA32_SPEC_CTRL value matches
> > the host value, there is no need to write the MSR on VM-{entry,exit}.
>
> With host setting the effective BHI_DIS_S for guest using virtual
> SPEC_CTRL, there will be no way for guest to opt-out of BHI mitigation.
> Or if the guest is mitigating BHI with the software sequence, it will
> still get the hardware mitigation also.
>
> To overcome this, the guest and KVM need to implement
> MSR_VIRTUAL_MITIGATION_CTRL to allow guest to opt-out of hardware
> mitigation.

I don't think there is much value in this additional complexity. If
the guest opts out of BHI mitigation, it will pay dearly for it,
because then the effective value of the guest IA32_SPEC_CTRL will not
be the same as the host value, and KVM will have to write the MSR on
every VM-{entry,exit}. That's likely to be a higher cost than
BHI_DIS_S in VMX non-root operation.

> > There is no need to disable BHI_DIS_S on the host and use the TSX
> > abort sequence in its place.
>
> Exactly.