linux-kernel - Re: [RFC PATCH v2 00/11] Intel IA32_SPEC

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 14 Apr 2023 15:10:17 -0700
From:   Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To:     Binbin Wu <binbin.wu@...ux.intel.com>
Cc:     Chao Gao <chao.gao@...el.com>, kvm@...r.kernel.org,
        Jiaan Lu <jiaan.lu@...el.com>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Babu Moger <babu.moger@....com>,
        Borislav Petkov <bp@...en8.de>, Borislav Petkov <bp@...e.de>,
        Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Matlack <dmatlack@...gle.com>,
        "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Kim Phillips <kim.phillips@....com>,
        Len Brown <len.brown@...el.com>, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org,
        Nikunj A Dadhania <nikunj@....com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Sandipan Das <sandipan.das@....com>,
        Sean Christopherson <seanjc@...gle.com>,
        Shuah Khan <shuah@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vitaly Kuznetsov <vkuznets@...hat.com>, x86@...nel.org,
        Zhang Chen <chen.zhang@...el.com>
Subject: Re: [RFC PATCH v2 00/11] Intel IA32_SPEC_CTRL Virtualization

On Fri, Apr 14, 2023 at 05:51:43PM +0800, Binbin Wu wrote:
> 
> On 4/14/2023 2:25 PM, Chao Gao wrote:
> > Changes since RFC v1:
> >   * add two kselftests (patch 10-11)
> >   * set virtual MSRs also on APs [Pawan]
> >   * enable "virtualize IA32_SPEC_CTRL" for L2 to prevent L2 from changing
> >     some bits of IA32_SPEC_CTRL (patch 4)
> >   * other misc cleanup and cosmetic changes
> > 
> > RFC v1: https://lore.kernel.org/lkml/20221210160046.2608762-1-chen.zhang@intel.com/
> > 
> > 
> > This series introduces "virtualize IA32_SPEC_CTRL" support. Here are
> > introduction and use cases of this new feature.
> > 
> > ### Virtualize IA32_SPEC_CTRL
> > 
> > "Virtualize IA32_SPEC_CTRL" [1] is a new VMX feature on Intel CPUs. This feature
> > allows VMM to lock some bits of IA32_SPEC_CTRL MSR even when the MSR is
> > pass-thru'd to a guest.
> > 
> > 
> > ### Use cases of "virtualize IA32_SPEC_CTRL" [2]
> > 
> > Software mitigations like Retpoline and software BHB-clearing sequence depend on
> > CPU microarchitectures. And guest cannot know exactly the underlying
> > microarchitecture. When a guest is migrated between processors of different
> > microarchitectures, software mitigations which work perfectly on previous
> > microachitecture may be not effective on the new one. To fix the problem, some
> > hardware mitigations should be used in conjunction with software mitigations.
> 
> So even the hardware mitigations are enabled, the software mitigations are
> still needed, right?

Retpoline mitigation is not fully effective when RET can take prediction
from an alternate predictor. Newer hardware provides a way to disable
this behavior (using RRSBA_DIS_S bit in MSR SPEC_CTRL).

eIBRS is the preferred way to mitigate BTI, but for some reason when a
guest has deployed retpoline, VMM can make it more effective by
deploying the relevant hardware control. That is why the above text
says:

  "... hardware mitigations should be used in conjunction with software
  mitigations."