RE: [RFC PATCH 27/34] x86/bugs: Add attack vector controls for spectre_v1

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Manwaring, Derek <derekmn@xxxxxxxxxx>
> Sent: Monday, September 30, 2024 7:40 PM
> To: Kaplan, David <David.Kaplan@xxxxxxx>
> Cc: bp@xxxxxxxxx; dave.hansen@xxxxxxxxx; dave.hansen@xxxxxxxxxxxxxxx;
> hpa@xxxxxxxxx; jpoimboe@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> mingo@xxxxxxxxxx; pawan.kumar.gupta@xxxxxxxxxxxxxxx;
> peterz@xxxxxxxxxxxxx; tglx@xxxxxxxxxxxxx; x86@xxxxxxxxxx
> 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