linux-kernel - Re: [PATCH] x86/amd: Disable RDSEED on AMD Zen5 Turin because of an error.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aPK-2iYHnt8DYFAF@zx2c4.com>
Date: Sat, 18 Oct 2025 00:10:34 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Gregory Price <gourry@...rry.net>
Cc: x86@...nel.org, 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, linux-crypto@...r.kernel.org, tytso@....edu
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.

Yikes. I suppose we should get some more info from AMD, so that they can
really figure out what's affected and why and such. In the meanwhile,
maybe it makes sense to disable a broad set of Zen 5 subfamilies? From a
random.c perspective, it'll use RDRAND instead, which appears to be
unaffected according to your report.

(Though, how could you tell if it was affected? RDRAND runs everything
 through its internal DRBG, so if part of the key that it uses is made of
 fixed zeros, we probably wouldn't notice. AMD really needs to look into
 this.)

Impact-wise on random.c, assuming the most pessimistic conditions -- no
other entropy source being used other than RDSEED, which is never
actually the case but good for analysis here -- the first usage of
getrandom() will use 512 bits (random_init_early()) + 256 bits
(extract_entropy()) = 768 bits of RDSEED output, so assuming your 10%
failure rate, that's still 688 bits, which is roughly 2.69x as much as
we really "need" anyway. So I suspect overkill engineering is saving us
a bit here, and there's not any security impact to random.c.

Users who don't use getrandom() and try to use RDSEED directly might be
in a different situation, however. Don't do this. Just use getrandom().

Jason