linux-kernel - Re: [PATCH RESEND v2 3/3] x86/cpu: Enable modifying bug flags with {clear,set}puid

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: <20250217111029.GIZ7MZJUGJRoeiScgn@fat_crate.local>
Date: Mon, 17 Feb 2025 12:10:29 +0100
From: Borislav Petkov <bp@...en8.de>
To: Brendan Jackman <jackmanb@...gle.com>
Cc: Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v2 3/3] x86/cpu: Enable modifying bug flags with
 {clear,set}puid

On Wed, Jan 29, 2025 at 03:35:41PM +0000, Brendan Jackman wrote:
> Sometimes it can be very useful to run CPU vulnerability mitigations on
> systems where they aren't known to mitigate any real-world
> vulnerabilities. This can be handy for mundane reasons like debugging
> HW-agnostic logic on whatever machine is to hand, but also for research
> reasons: while some mitigations are focused on individual vulns and
> uarches, others are fairly general, and it's strategically useful to
> have an idea how they'd perform on systems where they aren't currently
> needed.
> 
> As evidence for this being useful, a flag specifically for Retbleed was
> added in commit 5c9a92dec323 ("x86/bugs: Add retbleed=force").
> 
> Since CPU bugs are tracked using the same basic mechanism as features,
> and there are already parameters for manipulating them by hand, extend
> that mechanism to support bug as well as capabilities.
> 
> With this patch and setcpuid=srso, a QEMU guest running on an Intel host
> will boot with Safe-RET enabled.

As before. Move that sentence ...

> Signed-off-by: Brendan Jackman <jackmanb@...gle.com>
> ---

... here.

>  arch/x86/include/asm/cpufeature.h |  1 +
>  arch/x86/kernel/cpu/common.c      | 16 ++++++++++++----
>  2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
> index 0b9611da6c53f19ae6c45d85d1ee191118ad1895..6e17f47ab0521acadb7db38ce5934c4717d457ba 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -50,6 +50,7 @@ extern const char * const x86_power_flags[32];
>   * X86_BUG_<name> - NCAPINTS*32.
>   */
>  extern const char * const x86_bug_flags[NBUGINTS*32];
> +#define x86_bug_flag(flag) x86_bug_flags[flag]

Why?

>  #define test_cpu_cap(c, bit)						\
>  	 arch_test_bit(bit, (unsigned long *)((c)->x86_capability))
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e26cf8789f0e1a27ad126f531e05afee0fdebbb8..d94d7ebff42dadae30f77af1ef675d1a83ba6c3f 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1492,7 +1492,8 @@ static inline void parse_set_clear_cpuid(char *arg, bool set)
>  
>  		/*
>  		 * Handle naked numbers first for feature flags which don't
> -		 * have names.
> +		 * have names. It doesn't make sense for a bug not to have a
> +		 * name so don't handle bug flags here.
>  		 */
>  		if (!kstrtouint(opt, 10, &bit)) {
>  			if (bit < NCAPINTS * 32) {

It did but after

  7583e8fbdc49 ("x86/cpu: Remove X86_FEATURE_NAMES")

this chunk can be whacked now. Please do that in a pre-patch.

Thx.

-- 
Regards/Gruss,
    Boris.

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