linux-kernel - RE: [PATCH v3 20/35] x86/bugs: Define attack vectors

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:
 <LV3PR12MB9265078444D6B1B4258849FB94CD2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 27 Feb 2025 16:05:08 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
CC: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Josh Poimboeuf
	<jpoimboe@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
	<peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H . Peter
 Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 20/35] x86/bugs: Define attack vectors

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Thursday, February 27, 2025 9:37 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>; Josh Poimboeuf
> <jpoimboe@...nel.org>; Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra
> <peterz@...radead.org>; Ingo Molnar <mingo@...hat.com>; Dave Hansen
> <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Feb 27, 2025 at 03:22:08PM +0000, Kaplan, David wrote:
> > In this case, I think it is clearer to say
> > mitigations=auto;no_guest_guest
> >
> > That way, the admin is explicitly saying they don't want certain protection.
> > This seems much harder to mess up.
>
> So if we want to protect *only* against malicious VMs, the cmdline should be
>
> mitigations:off;no_guest_guest
>
> off being the policy to disable the other vectors because admin wants to have her
> performance back.
>
> Right?

No.  It should be 'mitigations=auto;no_user_kernel,no_user_user'

(And maybe add 'no_guest_guest' if they don’t care about the malicious VMs attacking each other)

>
> Which then makes this one:
>
> mitigations=off;guest_host
>
> equivalent.
>
> Uff.

Right, the question is do we support both opt-in and opt-out forms.  We can.  We could also start by only supporting opt-out form.

>
> > But there's already an 'auto,nosmt' option.  So I thought we wanted to
> > leave that alone and use it as the base.
>
> There's that. And "nosmt" is actually the cross-thread attack vector.
>
> I guess what we should do here is to leave "auto,nosmt" alone and use
> "cross_thread" for the attack vector and not allow "nosmt" in the new mitigations
> specification scheme.
>
> IOW, the set of the attack vectors will be:
>
> list_of_vectors = {user_kernel, user_user, guest_host, guest_guest, cross_thread }
>
> Or the no_ versions of them respectively.
>
> Hmmm.

As mentioned earlier in the thread, SMT really needs a tristate of:
1. All SMT mitigations including potentially disabling SMT
2. All SMT mitigations but excluding the possibility of disabling SMT (current default)
3. No SMT mitigations (not even things like STIBP)

There are various ways to encode that in the command line options.  'auto,nosmt' is already #1.  And just 'auto' is currently #2.

We could then add 'no_cross_thread' to support #3.  I think that was the latest proposal.

--David Kaplan