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:
 <LV3PR12MB926589C779479C836DA4E51D94772@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Tue, 1 Oct 2024 01:46:27 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: "Manwaring, Derek" <derekmn@...zon.com>
CC: "bp@...en8.de" <bp@...en8.de>, "dave.hansen@...el.com"
	<dave.hansen@...el.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "hpa@...or.com" <hpa@...or.com>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"pawan.kumar.gupta@...ux.intel.com" <pawan.kumar.gupta@...ux.intel.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "tglx@...utronix.de"
	<tglx@...utronix.de>, "x86@...nel.org" <x86@...nel.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: Manwaring, Derek <derekmn@...zon.com>
> Sent: Monday, September 30, 2024 7:40 PM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: bp@...en8.de; dave.hansen@...el.com; dave.hansen@...ux.intel.com;
> hpa@...or.com; jpoimboe@...nel.org; linux-kernel@...r.kernel.org;
> mingo@...hat.com; pawan.kumar.gupta@...ux.intel.com;
> peterz@...radead.org; tglx@...utronix.de; x86@...nel.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 2024-09-12 21:15+0000 David Kaplan wrote:
> > On 2024-09-12 13:16-0700 Dave Hansen wrote:
> > > 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.
>
> This makes sense, but I'm not sure it is a meaningful simplification for users. I
> think it'd be helpful if we had a few samples of how users normally configure
> their systems. My hunch would be there are three main
> camps:
>   1) default for everything
>   2) mitigations=off
>   3) specify at least one mitigation individually.
>
> I think you're saying group (3) is helped most because now they don't have to
> understand each individual mitigation. But (3) is perhaps already a very small
> group of users? Maybe it would help (1) as well because they would get
> performance gains, but I'm skeptical of how many would feel safe switching
> from defaults to a vector specification. If they do feel comfortable doing that,
> they're probably closer to (3). Is that fair?
>

I think these attack vector controls make it easier to configure say a system where userspace is trusted by VMs are not (such as with a cloud node).  Or a shared system where userspace is untrusted but only trusted users are allowed to run VMs, so the VMs are trusted.  I see those as potentially being more likely vs specifying mitigations individually (which I suspect very few people do).

If it was helpful, I could perhaps include these as examples in the documentation file.

--David Kaplan