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: <20250227140858.GEZ8Bx-tTaQF8D5WBj@fat_crate.local>
Date: Thu, 27 Feb 2025 15:08:58 +0100
From: Borislav Petkov <bp@...en8.de>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>,
	"Kaplan, David" <David.Kaplan@....com>,
	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 Wed, Feb 26, 2025 at 07:50:38PM -0800, Pawan Gupta wrote:
> Thats fair. I certainly don't want to be adding new option if we are
> willing to live with some minor quirks with auto,nosmt.
> 
> Like, should the order in which nosmt appears after =auto matter? IOW,
> "=auto,no_foo,nosmt" would be equivalent to "=auto,nosmt,no_foo"? I believe
> they should be treated the same.

Yes, they should be. The order within a single mitigations=<string> shouldn't
matter.

> So as to treat nosmt as any other attack vector, CPU_MITIGATIONS_AUTO_NOSMT
> should go away. I am thinking we can modify cpu_mitigations_auto_nosmt() to
> check for smt attack vector:

Looks like we're calling it an attack vector if I look at the cross-thread
section in the documentation patch:

https://lore.kernel.org/r/20250108202515.385902-20-david.kaplan@amd.com

So I guess the cmdline format should be something like:

mitigations=<global_vector_policy>;<list_of_vectors>

More concretely:

mitigations=(on|off|auto);((no)_<vector>)?

Btw, it probably would be better to split the global policy and the vectors
with ';' instead of ',' for an additional clarity and ease of parsing.

Before this goes out of hand with bikeshedding: please think about what
configurations we want to support and why and then design the command line
syntax - not the other way around.

I'm still not fully sold on the negative vector options. Although it sure does
save typing.

With my user hat on: If I have to do "no_user_kernel" then I probably need to
go look what else is there. Do I want it, need it? Dunno. Maybe.

If I do

mitigations=;no_user_kernel

then yeah, that would basically set everything else to "auto" and disable
user_kernel.

David still wants to warn if there's no global option supplied like "auto" but
we can simply assume it is meant "auto" but warn. This is the most intuitive
thing to do IMO.

And when it comes to warning about nonsensical options - yap, we should do so
when parsing.

A couple more random examples as food for bikeshedding:

mitigation=auto;nosmt,user_user	- running untrusted user stuff, prevent user
apps from attacking each-other, kernel protections are default

mitigations=off;guest_host - running untrusted VMs, protect host from them

mitigations=off;guest_host,guest_guest,cross_thread - cloud provider settings

Same thing with negative options should probably be

mitigations=;no_user_kernel,no_user_user

Hmm, I dunno: being able to specify the same thing in two different ways is
calling for trouble. I think we should keep it simple and do positive options
first and then consider negative if really really needed.

Thx.

-- 
Regards/Gruss,
    Boris.

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