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:
 <DS7PR12MB57665C3E8A7F0AF59E034B3C94D32@DS7PR12MB5766.namprd12.prod.outlook.com>
Date: Mon, 1 Jul 2024 13:40:19 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Amit Shah <amit@...nel.org>, Jim Mattson <jmattson@...gle.com>, Sean
 Christopherson <seanjc@...gle.com>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>, "x86@...nel.org"
	<x86@...nel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "hpa@...or.com"
	<hpa@...or.com>, "Phillips, Kim" <kim.phillips@....com>
Subject: RE: [PATCH v2] KVM: SVM: let alternatives handle the cases when RSB
 filling is required

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Amit Shah <amit@...nel.org>
> Sent: Monday, July 1, 2024 7:52 AM
> To: Jim Mattson <jmattson@...gle.com>; Sean Christopherson
> <seanjc@...gle.com>
> Cc: pbonzini@...hat.com; x86@...nel.org; kvm@...r.kernel.org; linux-
> kernel@...r.kernel.org; tglx@...utronix.de; mingo@...hat.com;
> bp@...en8.de; dave.hansen@...ux.intel.com; hpa@...or.com; Phillips, Kim
> <kim.phillips@....com>; Kaplan, David <David.Kaplan@....com>
> Subject: Re: [PATCH v2] KVM: SVM: let alternatives handle the cases when
> RSB filling is required
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On Fri, 2024-06-28 at 11:48 -0700, Jim Mattson wrote:
> > On Fri, Jun 28, 2024 at 9:09 AM Sean Christopherson
> > <seanjc@...gle.com> wrote:
> > >
> > > On Wed, Jun 26, 2024, Amit Shah wrote:
> > > > ---
> > > >  arch/x86/kvm/svm/vmenter.S | 8 ++------
> > > >  1 file changed, 2 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/arch/x86/kvm/svm/vmenter.S
> > > > b/arch/x86/kvm/svm/vmenter.S index a0c8eb37d3e1..2ed80aea3bb1
> > > > 100644
> > > > --- a/arch/x86/kvm/svm/vmenter.S
> > > > +++ b/arch/x86/kvm/svm/vmenter.S
> > > > @@ -209,10 +209,8 @@ SYM_FUNC_START(__svm_vcpu_run)
> > > >  7:   vmload %_ASM_AX
> > > >  8:
> > > >
> > > > -#ifdef CONFIG_MITIGATION_RETPOLINE
> > > >       /* IMPORTANT: Stuff the RSB immediately after VM-Exit,
> > > > before RET! */
> > > > -     FILL_RETURN_BUFFER %_ASM_AX, RSB_CLEAR_LOOPS,
> > > > X86_FEATURE_RETPOLINE
> > > > -#endif
> > > > +     FILL_RETURN_BUFFER %_ASM_AX, RSB_CLEAR_LOOPS,
> > > > X86_FEATURE_RSB_VMEXIT
> > >
> > > Out of an abundance of paranoia, shouldn't this be?
> > >
> > >         FILL_RETURN_BUFFER %_ASM_CX, RSB_CLEAR_LOOPS,
> > > X86_FEATURE_RSB_VMEXIT,\
> > >                            X86_FEATURE_RSB_VMEXIT_LITE
> > >
> > > Hmm, but it looks like that would incorrectly trigger the "lite"
> > > flavor for
> > > families 0xf - 0x12.  I assume those old CPUs aren't affected by
> > > whatever on earth EIBRS_PBRSB is.
> > >
> > >         /* AMD Family 0xf - 0x12 */
> > >         VULNWL_AMD(0x0f,        NO_MELTDOWN | NO_SSB | NO_L1TF |
> > > NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_BHI),
> > >         VULNWL_AMD(0x10,        NO_MELTDOWN | NO_SSB | NO_L1TF |
> > > NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_BHI),
> > >         VULNWL_AMD(0x11,        NO_MELTDOWN | NO_SSB | NO_L1TF |
> > > NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_BHI),
> > >         VULNWL_AMD(0x12,        NO_MELTDOWN | NO_SSB | NO_L1TF |
> > > NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO | NO_BHI),
> > >
> > >         /* FAMILY_ANY must be last, otherwise 0x0f - 0x12 matches
> > > won't work */
> > >         VULNWL_AMD(X86_FAMILY_ANY,      NO_MELTDOWN | NO_L1TF |
> > > NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO |
> NO_EIBRS_PBRSB |
> > > NO_BHI),
> > >         VULNWL_HYGON(X86_FAMILY_ANY,    NO_MELTDOWN | NO_L1TF |
> > > NO_MDS | NO_SWAPGS | NO_ITLB_MULTIHIT | NO_MMIO |
> NO_EIBRS_PBRSB |
> > > NO_BHI),
> >
> > Your assumption is correct. As for why the cpu_vuln_whitelist[]
> > doesn't say so explicitly, you need to read between the lines...
> >
> > >        /*
> > >         * AMD's AutoIBRS is equivalent to Intel's eIBRS - use the
> > > Intel feature
> > >         * flag and protect from vendor-specific bugs via the
> > > whitelist.
> > >         *
> > >         * Don't use AutoIBRS when SNP is enabled because it degrades
> > > host
> > >         * userspace indirect branch performance.
> > >         */
> > >        if ((x86_arch_cap_msr & ARCH_CAP_IBRS_ALL) ||
> > >            (cpu_has(c, X86_FEATURE_AUTOIBRS) &&
> > >             !cpu_feature_enabled(X86_FEATURE_SEV_SNP))) {
> > >                setup_force_cpu_cap(X86_FEATURE_IBRS_ENHANCED);
> > >                if (!cpu_matches(cpu_vuln_whitelist, NO_EIBRS_PBRSB)
> > > &&
> > >                    !(x86_arch_cap_msr & ARCH_CAP_PBRSB_NO))
> > >                        setup_force_cpu_bug(X86_BUG_EIBRS_PBRSB);
> > >        }
> >
> > Families 0FH through 12H don't have EIBRS or AutoIBRS, so there's no
> > cpu_vuln_whitelist[] lookup. Hence, no need to set the NO_EIBRS_PBRSB
> > bit, even if it is accurate.
>
> The commit that adds the RSB_VMEXIT_LITE feature flag does describe the
> bug in a good amount of detail:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> d=2b1299322016731d56807aa49254a5ea3080b6b3
>
> I've not seen any indication this is required for AMD CPUs.
>
> David, do you agree we don't need this?
>

It's not required, as AMD CPUs don't have the PBRSB issue with AutoIBRS.  Although I think Sean was talking about being extra paranoid

--David Kaplan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ