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: <aPFDn-4Cm6n0_3_e@gourry-fedora-PF4VCD3F>
Date: Thu, 16 Oct 2025 15:12:31 -0400
From: Gregory Price <gourry@...rry.net>
To: x86@...nel.org
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
	peterz@...radead.org, mario.limonciello@....com, riel@...riel.com,
	yazen.ghannam@....com, me@...aill.net, kai.huang@...el.com,
	sandipan.das@....com, darwi@...utronix.de, stable@...nel.org
Subject: Re: [PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an
 error.

On Thu, Oct 16, 2025 at 02:21:07PM -0400, Gregory Price wrote:
> Under unknown architectural conditions, Zen5 chips running rdseed
> can produce (val=0,CF=1) as a "random" result over 10% of the time
> (when rdseed is successful).  CF=1 indicates success, while val=0
> is typically only produced when rdseed fails (CF=0).
> 
> This suggests there is an architectural issue which causes rdseed
> to misclassify a failure as a success under unknown conditions.
> 
> This was reproduced reliably by launching 2-threads per available
> core, 1-thread per for hamming on RDSEED, and 1-thread per core
> collectively eating and hammering on ~90% of memory.
> 
> Fix was modeled after a different RDSEED issue in Zen2 Cyan Skillfish.
> 
> Link: https://lore.kernel.org/all/20250715130819.461718765@linuxfoundation.org/
> Cc: <stable@...nel.org>
> Signed-off-by: Gregory Price <gourry@...rry.net>
> ---
>  arch/x86/kernel/cpu/amd.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 5398db4dedb4..9c3b2f010f8c 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1037,6 +1037,12 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
>  
>  static void init_amd_zen5(struct cpuinfo_x86 *c)
>  {
> +	/* Disable RDSEED on AMD Turin because of an error. */
> +	if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {

After re-examining the results, this was also observed on

  c->x86_model == 0x2

Maybe this should just be disabled for all of Zen5?
I will wait for comment.

In a stress test (link) I found that my Zen5 chips have a bizarrely
low rdseed success rate anyway - so it doesn't even seem useful.

./rdseed_stress_single_core
RDRAND: 100.00%, RDSEED: 3.48%

./rdseed_stress_multi_thread
RDRAND: 99.99%, RDSEED: 0.33%

Link: https://lore.kernel.org/all/Zbjw5hRHr_E6k18r@zx2c4.com/

---

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 9c3b2f010f8c..54f07514674a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1038,7 +1038,8 @@ static void init_amd_zen4(struct cpuinfo_x86 *c)
 static void init_amd_zen5(struct cpuinfo_x86 *c)
 {
        /* Disable RDSEED on AMD Turin because of an error. */
-       if (c->x86_model == 0x11 && c->x86_stepping == 0x0) {
+       if ((c->x86_model == 0x11 || c->x86_model == 0x2) &&
+           (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");

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ