linux-kernel - RE: [RFC PATCH 27/34] x86/bugs: Add attack vector controls 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:
 <LV3PR12MB926575E4BB94AE51EA662A3694642@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 12 Sep 2024 21:15:17 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Dave Hansen <dave.hansen@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>, Peter Zijlstra <peterz@...radead.org>, Josh
 Poimboeuf <jpoimboe@...nel.org>, Pawan Gupta
	<pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, Dave
 Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H .
 Peter Anvin" <hpa@...or.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 27/34] x86/bugs: Add attack vector controls for
 spectre_v1

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Dave Hansen <dave.hansen@...el.com>
> Sent: Thursday, September 12, 2024 3:17 PM
> To: Kaplan, David <David.Kaplan@....com>; Thomas Gleixner
> <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter Zijlstra
> <peterz@...radead.org>; Josh Poimboeuf <jpoimboe@...nel.org>; Pawan
> Gupta <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar
> <mingo@...hat.com>; Dave Hansen <dave.hansen@...ux.intel.com>;
> x86@...nel.org; H . Peter Anvin <hpa@...or.com>
> Cc: linux-kernel@...r.kernel.org
> Subject: Re: [RFC PATCH 27/34] x86/bugs: Add attack vector controls for
> spectre_v1
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 9/12/24 12:57, Kaplan, David wrote:
> > And to be clear, I was trying to continue to support both.  But the
> > attack-vector style is also more future-proof because when new issues
> > arise, they would get added to the appropriate vectors and users
> > wouldn't have to do anything ideally.
>
> That's a good point.  Do you have any inkling about how static folks'
> vector selection would have been over time?
>
> For instance, if someone cared about CPU_MITIGATE_GUEST_HOST at the
> original spectre_v2 time, did that carry forward to L1TF and all the way into
> 2024?
>
> Or would they have had to shift their vector selection over time?

In my view, the attack vector selection is a function of how the system is being used.  A system that runs untrusted guests and cared about spectre_v2 I would think also cares about L1TF, Retbleed, etc. They're all attacks that can leak the same kind of data, although the mechanisms of exploit are different.  In what I've personally seen, if you care about one attack along a certain attack vector, you tend to care about all of them.

Now that said, there could be risk decisions based on the characteristics of individual bugs.  And that’s one reason why this RFC proposes that the bug-specific options always override the attack vector selection (in either direction).

--David Kaplan