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: <20250217201910.crsu7xucsa4dz3ub@jpoimboe>
Date: Mon, 17 Feb 2025 12:19:10 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: "Kaplan, David" <David.Kaplan@....com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
	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 Mon, Feb 17, 2025 at 05:33:24PM +0000, Kaplan, David wrote:
> So actually this doesn't quite work because the code in
> arch/x86/mm/pti.c has to call cpu_mitigate_attack_vector in order to
> check if PTI is required (it checks if user->kernel mitigations are
> needed).  That's the only use of the attack vectors outside of bugs.c.
> 
> The original code (using a function and WARN_ON_ONCE) can work, or I
> could perhaps create a pti-specific function in bugs.c that the pti
> code can query.  But right now I don't think there is any pti-related
> code in bugs.c at all.
> 
> Any suggestion?

Hm.  We *could* put the cpu_mitigate_attack_vector() macro in bugs.h and
make the array global (and possibly exported).  That way anybody could
call it, but it would still have the compile-time check.

However... should these not actually be arch-generic options, like
mitigations= already is?  It would make for a more consistent user
interface across arches.

They could even be integrated into the "mitigations=" interface.  The
options could be combined in any order (separated by commas):

  mitigations=user_kernel,user_user
  mitigations=guest_host,user_kernel
  ...etc...

And e.g., "mitigations=off" would simply disable all the vectors.

That would remove ambiguity created by combining mitigations= with
mitigate_* and would make it easier for all the current
cpu_mitigations_off() callers: only one global enable/disable interface
to call instead of two.  Any code calling cpu_mitigations_off() should
probably be calling something like cpu_mitigate_attack_vector() instead.

cpu_mitigations_off() and cpu_mitigations_auto_nosmt() could be
deprecated in favor of more vector-specific interfaces, and could be
removed once all the arches stop using them.  They could be gated by a
temporary ARCH_USES_MITIGATION_VECTORS option.  As could the per-vector
cmdline options.

Thoughts?

-- 
Josh