linux-kernel - Re: [PATCH v2 1/1] x86/rdrand: disable RDSEED on AMD Cyan Skillfish

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] [day] [month] [year] [list]

Message-ID: <20250524161133.GBaDHvtdqNIztnFogw@fat_crate.local>
Date: Sat, 24 May 2025 18:11:33 +0200
From: Borislav Petkov <bp@...en8.de>
To: Mikhail Paulyshka <me@...aill.net>
Cc: Mario Limonciello <mario.limonciello@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] x86/rdrand: disable RDSEED on AMD Cyan Skillfish

On Sat, May 24, 2025 at 05:53:19PM +0300, Mikhail Paulyshka wrote:
> AMD Cyan Skillfish (Family 17h, Model 47h, Stepping 0h) has an
> error that causes RDSEED to always return 0xffffffff, while RDRAND
> works correctly.
> 
> This patch masks the RDSEED cap for this CPU so that both

s/This patch masks/Mask/

> /proc/cpuinfo and direct CPUID read report RDSEED as unavailable.
> 
> 
> v2:
>   * Limit changes to AMD Cyan Skillfish
>   * Replace the runtime RDSEED sanity check with a simple
>     family/model/stepping match

Changelog stuff goes...

> 
> Signed-off-by: Mikhail Paulyshka <me@...aill.net>
> ---

<--- ... here, under the "---" so that patch handling scripts can ignore it.

>  arch/x86/include/asm/msr-index.h       | 1 +
>  arch/x86/kernel/cpu/rdrand.c           | 9 +++++++++
>  tools/arch/x86/include/asm/msr-index.h | 1 +
>  3 files changed, 11 insertions(+)
> 
> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
> index e7d2f460fcc6..2333f4e7bc2f 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -624,6 +624,7 @@
>  #define MSR_AMD64_OSVW_STATUS		0xc0010141
>  #define MSR_AMD_PPIN_CTL		0xc00102f0
>  #define MSR_AMD_PPIN			0xc00102f1
> +#define MSR_AMD64_CPUID_FN_7		0xc0011002
>  #define MSR_AMD64_CPUID_FN_1		0xc0011004
>  #define MSR_AMD64_LS_CFG		0xc0011020
>  #define MSR_AMD64_DC_CFG		0xc0011022
> diff --git a/arch/x86/kernel/cpu/rdrand.c b/arch/x86/kernel/cpu/rdrand.c
> index eeac00d20926..c474d0a5c317 100644
> --- a/arch/x86/kernel/cpu/rdrand.c
> +++ b/arch/x86/kernel/cpu/rdrand.c
> @@ -11,6 +11,7 @@
>  #include <asm/processor.h>
>  #include <asm/archrandom.h>
>  #include <asm/sections.h>
> +#include <asm/msr.h>
>  
>  /*
>   * RDRAND has Built-In-Self-Test (BIST) that runs on every invocation.
> @@ -47,4 +48,12 @@ void x86_init_rdrand(struct cpuinfo_x86 *c)
>  		clear_cpu_cap(c, X86_FEATURE_RDSEED);
>  		pr_emerg("RDRAND is not reliable on this platform; disabling.\n");
>  	}
> +
> +	/* disable RDSEED on AMD Cyan Skillfish because of hw bug */

Not a hw bug - "... has an error" above was closer :-)

> +	if (c->x86_vendor == X86_VENDOR_AMD && c->x86 == 0x17 &&
> +	    c->x86_model == 0x47 && c->x86_stepping == 0x0) {
> +		clear_cpu_cap(c, X86_FEATURE_RDSEED);
> +		msr_clear_bit(MSR_AMD64_CPUID_FN_7, 18);
> +		pr_emerg("RDSEED is not reliable on this platform; disabling.\n");
> +	}
>  }
> diff --git a/tools/arch/x86/include/asm/msr-index.h b/tools/arch/x86/include/asm/msr-index.h
> index e6134ef2263d..8b48a54b627a 100644
> --- a/tools/arch/x86/include/asm/msr-index.h
> +++ b/tools/arch/x86/include/asm/msr-index.h
> @@ -616,6 +616,7 @@
>  #define MSR_AMD64_OSVW_STATUS		0xc0010141
>  #define MSR_AMD_PPIN_CTL		0xc00102f0
>  #define MSR_AMD_PPIN			0xc00102f1
> +#define MSR_AMD64_CPUID_FN_7		0xc0011002
>  #define MSR_AMD64_CPUID_FN_1		0xc0011004
>  #define MSR_AMD64_LS_CFG		0xc0011020
>  #define MSR_AMD64_DC_CFG		0xc0011022
> -- 

In any case, those are just minor nits which can be dealt with when applying.

Otherwise, patch looks good, thanks.

We have merge window upcoming next week so I'll take it after that but it is
on my list of patches to take after the MW.

-- 
Regards/Gruss,
    Boris.

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