AMD’s RDSEED issue with Zen 5 processors that is in the process of being addressed with microcode/BIOS updates is in the interim causing headaches for Arch Linux powered CachyOS that provides optimized binaries for these latest Ryzen processors.
Merged last week for Linux Git is a patch to workaround RDSEED usage with existing CPU microcode versions where this RDSEED issue is present. But that kernel patch in turn is causing issues for CachyOS binaries built with -march=znver5 where the code ends up blindly assuming that RDSEED usage is permitted.
CachyOS developer Peter Jung raised the issue on the kernel mailing list:
“This fix seems to break quite a bunch of users in CachyOS. There has been now several users reporting that there system can not get properly into the graphical interface.
CachyOS is compiling the packages with -march=znver5 and the GCC compiler currently does pass RDSEED.
This patch results into that also Client CPUs (Strix Point, Granite Ridge), can not execute this. There has been a microcode fix deployed in linux-firmware for Turin, but no other microcode changes seen yet.
I think it would be possible to exclude clients or providing a fix for this.”
AMD Linux engineer Borislav Petkov suggested a simple patch to just provide a warning around RDSEED being broken and not clearing the feature bit. That may work for carrying by the CachyOS kernel as an interim measure until the Ryzen 9000 series / Ryzen AI 300 series microcode updates are available. Petkov added in his LKML post:
“Yah, the compiler should not *pass* RDSEED, but issue code which checks whether RDSEED is there. Otherwise what’s the point of CPUID flags?!
I guess this should make those boxes boot but damn, that ain’t right…Client fixes are getting ready but I can’t tell you when they’ll be there.”
Meanwhile Intel Fellow Thomas Gleixner added to the discussion:
“You get what you ask for. You build a binary for a CPU which does not provide a functional correct RDSEED16/32 instruction.
…
There are only two fixes:1) New microcode
2) Fix all source code to either use the 64bit variant of RDSEED or check the result for 0 and treat it like RDSEED with CF=0 (fail) or make it check the CPUID bit….
New microcode will come around soon and fixing all source code is not possible.
Excluding clients is not an option because that leaves anything crypto related which relies on randomness with a big hole. Clients require functional crypto as much as any other system, no?
So the only workaround for now is to use a build which does not emit RDSEED or checks CPUID for availability before blindly using it.”
This is one of the rare cases where Linux distributions providing optimized binaries like CachyOS with -march=znver5 can cause issues. Granted, the rest of the time the performance benefits of doing so can be quite enticing.
