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: <20250227150143.GFZ8B-V8nIdSlV7ng7@fat_crate.local>
Date: Thu, 27 Feb 2025 16:01:43 +0100
From: Borislav Petkov <bp@...en8.de>
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" <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

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 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?

Probably. Maybe.

So if the admin really wants to do that, then she'll have to say:

mitigations=off;guest_host,no_guest_guest

I guess that can be specified with this cmdline.

I guess if she would want to enable both guest_host and guest_guest, then the
cmdline should be

mitigations=auto;no_user_kernel,no_user_user

or the shorter version

mitigations=;no_user_kernel,no_user_user

Hmmm, something still feels weird... I still can't go "oh yeah, this is a good
form." ;-\

> 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?
:-P

> 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. :-\

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.

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?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette