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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALMp9eTQUznmXKAGYpes=A0b1BMbyKaCa+QAYTwwftMN3kufLA@mail.gmail.com>
Date: Fri, 13 Sep 2024 16:04:56 -0700
From: Jim Mattson <jmattson@...gle.com>
To: Chao Gao <chao.gao@...el.com>
Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.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 11:39 AM Jim Mattson <jmattson@...gle.com> wrote:
>
> On Thu, Sep 12, 2024 at 10:29 PM Chao Gao <chao.gao@...el.com> wrote:
> >
> > On Thu, Sep 12, 2024 at 09:24:40AM -0700, Pawan Gupta wrote:
> > >On Thu, Sep 12, 2024 at 03:44:38PM +0000, Jon Kohler wrote:
> > >> > It is only worth implementing the long sequence in VMEXIT_ONLY mode if it is
> > >> > significantly better than toggling the MSR.
> > >>
> > >> Thanks for the pointer! I hadn’t seen that second sequence. I’ll do measurements on
> > >> three cases and come back with data from an SPR system.
> > >> 1. as-is (wrmsr on entry and exit)
> > >> 2. Short sequence (as a baseline)
> > >> 3. Long sequence
> > >
> > >I wonder if virtual SPEC_CTRL feature introduced in below series can
> > >provide speedup, as it can replace the MSR toggling with faster VMCS
> > >operations:
> >
> > "virtual SPEC_CTRL" won't provide speedup. the wrmsr on entry/exit is still
> > need if guest's (effective) value and host's value are different.
>
> I believe that is the case here. The guest's effective value is 1025.
> If the guest knew about BHI_DIS_S, it would actually set it to 1025,
> but older guests set it to 1.
>
> 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}.

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

Besides, with the TSX abort approach, what are you going to do about
guests that *do* set BHI_DIS_S? If that bit is clear on the host,
they'll suffer the overhead of writing the MSR on VM-{entry,exit}.

> > "virtual SPEC_CTRL" just prevents guests from toggling some bits. It doesn't
> > switch the MSR between guest value and host value on entry/exit. so, KVM has
> > to do the switching with wrmsr/rdmsr instructions. A new feature, "load
> > IA32_SPEC_CTRL" VMX control (refer to Chapter 15 in ISE spec[*]), can help but
> > it isn't supported on SPR.
> >
> > [*]: https://cdrdv2.intel.com/v1/dl/getContent/671368
> >
> > >
> > >  https://lore.kernel.org/kvm/20240410143446.797262-1-chao.gao@intel.com/
> > >
> > >Adding Chao for their opinion.
> >