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: <9de4f491-eb64-4a1e-a375-7bc2d382fe5e@amazon.com>
Date: Mon, 30 Sep 2024 17:39:55 -0700
From: "Manwaring, Derek" <derekmn@...zon.com>
To: <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

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?

Derek