Linuxeden开源社区AMD Zen 5 处理器的 RDSEED 问题，目前正在通过微代码/BIOS 更新得到解决，但在此期间给基于 Arch Linux 的 CachyOS 带来了麻烦。CachyOS 为这些最新的 Ryzen 处理器提供优化后的二进制文件。
上周合并到 Linux Git 的补丁是为了解决现有 CPU 微码版本中存在的 RDSEED 使用问题。但这个内核补丁反过来又给使用-march=znver5 构建的 CachyOS 二进制文件带来了问题，因为代码会盲目地假设 RDSEED 的使用是被允许的。
CachyOS 开发者 Peter Jung 在内核邮件列表上提出了这个问题：
“这个修复似乎让 CachyOS 的许多用户遇到了问题。现在已有几名用户报告称，他们的系统无法正确进入图形界面。
CachyOS 正在使用-march=znver5 编译包，而 GCC 编译器目前并未通过 RDSEED。
这个补丁导致客户端 CPU（Strix Point，Granite Ridge）也无法执行此操作。在 linux-firmware 的 Turin 中已经部署了一个微代码修复，但尚未看到其他微代码更改。
我认为可以排除客户端或提供这个问题的修复。”
AMD Linux 工程师 Borislav Petkov 提出一个简单的补丁，只是提供关于 RDSEED 损坏的警告，并不清除特性位。这可能作为 CachyOS 内核的临时措施，直到 Ryzen 9000 系列/ Ryzen AI 300 系列微码更新可用。Petkov 在他的 LKML 帖子中补充道：
“是的，编译器不应该*传递*RDSEED，而应该发出检查 RDSEED 是否存在的代码。否则 CPUID 标志有什么意义？！
我想这应该能让那些盒子启动，但该死，这不对……客户端修复正在准备中，但我不能告诉你它们何时会到来。”
同时，英特尔高级工程师 Thomas Gleixner 加入了讨论：
你得到你所要求的。你为不支持功能正确的 RDSEED16/32 指令的 CPU 构建了一个二进制文件。
…
只有两个解决方案：1) 新的微代码
2) 修复所有源代码，使其使用 RDSEED 的 64 位变体或检查结果是否为 0，并将其视为 CF=0（失败）的 RDSEED，或者让它检查 CPUID 位。
新微代码很快就会推出，但修复所有源代码是不可能的。
排除客户端不是选项，因为这会留下任何依赖随机性的加密相关内容，留下一个大漏洞。客户端和其他系统一样，需要功能性的加密，不是吗？
因此，目前唯一的解决方案是使用不发出 RDSEED 或在使用前检查 CPUID 是否可用的构建。”
这是少数几个 Linux 发行版提供像 CachyOS 这样的优化二进制文件（使用-march=znver5）可能导致问题的案例之一。诚然，在其他时候，这样做带来的性能优势可能相当诱人。
转自 AMD’s Zen 5 RDSEED Issue Is Causing Headaches For Optimized CachyOS Builds – Phoronix