Formal statement that proof shall be provided by 'YOU" AKA "all of them" & so forth

https://www.phoronix.com/news/RDSEED-Disable-All-Zen-5

Price commented on the updated patch:
"Under unknown conditions, Zen5 chips running rdseed can produce (val=0,CF=1) 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 a bug which causes rdseed to silently fail.

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.

This was observed on more than 1 Zen5 model, so it should be disabled for all of Zen5 until/unless a comprehensive blacklist can be built."

Under those conditions amd has the right for legal justification of the matter of linux random seeding production,

It is my determination that under the described protocols, Most Linux 'Socalled" Software dev/random .. Solutions would suitably FAIL..

I personally believe anyway,

Because there are several factors at play:

1a Dev Linux is harassing CPU Random protocols...

1b No software solution is cache or ram raiding immune, In regard to bugs like zombi bleed..

1c It implies that INTEL & AMD are leaving a breach, In terms of the NSA

1d The exact amount of random seeds that hardware dev/random devices are expected to use, When compared to linux OS habits of using hardware rand under the shield of software hashed random

1e Hammering dev/random & also with havged & with crypto devices ... only provides a certain amount of random hashes as my post explains & proves...

1f Without haveged mostly linux software random is totally useless in terms of harden

references:

Chaos
https://science.n-helix.com/2022/02/interrupt-entropy.html
https://science.n-helix.com/2022/02/rdseed.html
https://science.n-helix.com/2020/06/cryptoseed.html

Signed Rupert S