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

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:
 <LV3PR12MB92651F3CE777A3723B61835594CD2@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Thu, 27 Feb 2025 15:22:08 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Borislav Petkov <bp@...en8.de>
CC: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, Josh Poimboeuf
	<jpoimboe@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Peter Zijlstra
	<peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>, "H . Peter
 Anvin" <hpa@...or.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3 20/35] x86/bugs: Define attack vectors

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Borislav Petkov <bp@...en8.de>
> Sent: Thursday, February 27, 2025 9:02 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>; Josh Poimboeuf
> <jpoimboe@...nel.org>; Thomas Gleixner <tglx@...utronix.de>; Peter Zijlstra
> <peterz@...radead.org>; Ingo Molnar <mingo@...hat.com>; Dave Hansen
> <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> <hpa@...or.com>; linux-kernel@...r.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