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: <5793efb7-358f-4796-bdf4-985c41f80ae5@amazon.com>
Date: Tue, 1 Oct 2024 15:18: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>,
	<derekmn@...zon.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-10-01 01:45+0000 David Kaplan wrote:
> On 2024-09-30 17:39-0700 Derek Manwaring wrote:
> > 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).

Ok I see the potential for those cases. I still wonder whether the extra
complexity for everyone is worth the benefits to those users.

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

I think the examples would help, yeah.

Derek