RE: [PATCH v3 20/35] x86/bugs: Define attack vectors

Kaplan, David
2025-02-27T15:22:10Z

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@alien8.de>
> Sent: Thursday, February 27, 2025 9:02 AM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>; Josh Poimboeuf
> <jpoimboe@kernel.org>; Thomas Gleixner <tglx@linutronix.de>; Peter Zijlstra
> <peterz@infradead.org>; Ingo Molnar <mingo@redhat.com>; Dave Hansen
> <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 20/35] x86/bugs: Define attack vectors
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Thu, Feb 27, 2025 at 02:36:37PM +0000, Kaplan, David wrote:
>
> > My 2 cents is I think the negative option form is better. That's
> > because I'd rather err on the side of safety if the user forgets something.
> >
> > For instance, in the case of 'mitigations=off;guest_host' there would
> > be no
> > guest->guest protection. Did the user really intend for that? Or did
> > guest->they
> > simply forget to think about that attack vector? In this case, their
> > error leaves the system potentially insecure.
>
> Well, good question. It could be that or it could be that the admin only cares about
> protecting the host from malicious VMs but not the VMs amongst each other. Does
> this use case make sense?

In this case, I think it is clearer to say
mitigations=auto;no_guest_guest

That way, the admin is explicitly saying they don't want certain protection. This seems much harder to mess up.

>
> > But if we only support the opt-out form, like
> > 'mitigations=auto;no_guest_host' and the user forgot about
> > guest->guest, it would leave those protections enabled. Potentially
> > reducing performance more than intended, but the system is more secure.
>
> Still don't know for sure what the admin wanted: more perf or more security?
>

My argument is it's probably better to err on the side of security.

>
> > Because the existing kernel defaults things to on (the auto setting)
> > and requires action to disable mitigations, why not keep the same
> > logic here and only support the opt-out form?
> >
> > Some specific use case examples might be:
> > 'mitigations=auto;no_guest_guest,no_guest_host' -- Running trusted VMs
> > 'mitigations=auto;no_user_kernel,no_user_user' -- Running untrusted
> > VMs but trusted userspace (cloud provider setting)
> > 'mitigations=auto;no_cross_thread' -- Using core scheduling
>
> I guess those make sense if you write them this way.
>
> With the opt-out-only strategy, enabling a single vector would require you to specify
> all others as no_*.
>
> mitigations=auto,no_user_kernel,no_guest_host,no_guest_guest,no_cross_thread
>
> That'll give you user_user.
>
> Yeah, I guess we can't have the cake and eat it too. :-\

To me this seems like an unlikely use case, so maybe it's ok to be a bit more verbose.

And of course, we can add more options later...we just can't remove anything we add now.

>
> Which reminds me: on boot we should printk which attack vector got enabled and
> which got disabled.
>
> And then have that same info in
>
> /sys/devices/system/cpu/vulnerabilities/attack_vectors
>
> or so.

Ok, I can add that to the series.

>
> So that we can verify what got configured.
>
> > On the SMT piece, I think the proposal is:
> > 'auto;<attack vectors>' -- Default SMT protections (enable cheap ones
> > like STIBP, but never disable SMT) 'auto,nosmt;<attack vectors>' --
> > Full SMT protections, including disabling SMT if required
>
> Well, that's the question: cross-thread or nosmt is yet another attack vector.
> So if we define the format as I mentioned above, this should be
>
> auto;<attack_vectors>,nosmt or "cross_thread".
>
> Right?

But there's already an 'auto,nosmt' option. So I thought we wanted to leave that alone and use it as the base.

--David Kaplan