Since I installed the Fedora Linux (6. 17.7-300 fc43.x86_64) 43 (Workstation Edition) update on my Framework 13 AMD Ryzen AI 300 Series - Ryzen AI 5 340, upon booting this message comes up “[RDSEED32 is broken. Disabling the corresponding CPUID bit.]” . This wasn’t fixed with the most recent update either (6. 17.8-300 fc43.x86_64) 43 (Workstation Edition). So now when I boot it up, after the message disappers, it comes up with a menu of the different updates, and upon clicking the the most recent at the top, it goes to the screen where you enter your passkey. Only now, when you press the keys to enter the passkey, nothing happens. I now have to press and hold the power button to turn it off, turn it on again, and instead click the last version from before the problematic updates (6. 17.6-300 fc43.x86_64) 43 (Workstation Edition). How can this be sorted (I’m fairly good with computers, but not beyond basic problems)? Thanks
I assume you’re seeing this issue
Update your AGESA firmware when it’s released. Until then, boot from the kernel which is not performing this check and fiddling with the CPUID flags.
Alternatively, you can add the clearcpuid=rdseed flag to the kernel until the AGESA firmware is released, at which point in time I assume you can then remove it from subsequent kernels
Thanks, I’ll give these a go tomorrow.
I have exactly the same issue as @wedsa25 and tried adding the clearcpuid=rdseed to the grub boot command while running under 6.17.7-300, but that didn’t resolve the issue when booting with 6.17.8-300. The LUKS password prompt doesn’t accept any typed characters and the laptop (ThinkPad 14s gen6 AMD) wouldn’t turn off or respond to Ctl-Alt-Del - hard reset required. According to AMD a firmware fix is due around 25-Nov.
How did you add the kernel parameter? Using grubby or did you manually add it to the boot parameters in the grub menu?
# vi /etc/default/grub
# grub2-mkconfig -o /boot/grub2/grub.cfg
SOLVED, and sorry for the false alarm. I added the clearcpuid=rdseed again and rebooted - this time I could unlock LUKS partition and boot into 6.17.8-300 kernel. So, I must have had a typo the first time.
I’m having the same thing happening.
The LUKS password form doesn’t show characters being typed in as dots, but it is receiving them, and, subsequently, unlocking the LUKS partition as expected. You didn’t need the kernel option for it to continue to work.
Splendid - let’s see if AMD (and specifically Framework in the OP’s case) can sort this out and produce a patched and corrected AGESA update on the 25th or thereabouts.
If memory serves there was some other post on here about a suspiciously similar situation where a user was (apparently) unable to unlock his encrypted device as the keyboard was dead… wonder if it’s related.
Woke up to this issue today, device is a ThinkPad T14 Gen 6 (Ryzen Ai 5 Pro 340).
Couldn’t get the clearcpuid=rdseed patch to work tho.
Edit : Tried to reapply the flag again, booted up 6.17.8-300 and still not working. Reverted the changes and will wait for official patch.
Unfortunately it appears we may need to wait a week or two or more for the next linux-firmwarerelease as it seems the AMD microcode/ucode fix landed two days after (Nov 13) the latest release (Nov 11). Some more context was noted here during Fedora testing of kernel v6.17.8 prior to it being pushed to stable.
Will the problem be solved after the patch, with a firmware update from the backup kernel?
Here’s a summary of all the kernel and firmware changes needed. There is no reason fedora can’t pick these up now.
Just wanted to say that I’m having the same issue, ThinkPad T14s AMD Ryzen AI 7 360. Doesn’t bother me too much, but a nice reminder to check the status of my firmware in general.
Same problem here with the same device. Just want to point out that, although I seems that you can not type your passkey, you are actually typing, there is no feedback, but if you type and hit “enter“ you get in, just have to wait a bit longer.
That’s right, it just doesn’t display the characters being typed. Same reported by @jrredho above.
So if I understand correctly, us end-users will simply have to wait for Fedora’s next kernel update, we cannot install this AGESA patch directly from AMD? There’s no patch yet despite it being later than November 25, I’m just wondering. Apologies if this is a silly question, i am noob. Apology applies to also this next question:
Also, what is the problem with using RDSEED in 64 bit form? Wouldn’t it be actually more cryptographically robust, anyway? I kind of want to research the way to switch mine to 64bit, and maybe just keep it this way, would that be sensible? Asking because it is one of the options suggested by AMD, at least temporarily.
Any updates on this? Been dealing with this as well.
Fedora 43, AMD Ryzen 350 CPU, Kernel 6.17.8-300.fc43.x86_64
AGESA is part of the BIOS on AMD mainboards. When AMD releases new AGESA versions, mainboard makers need to release a new BIOS with the new AGESA.
RDSEED64 is fine, however, there is only one CPUID bit to identify support for RDSEED. If the bit is set, applications know they can use the RDSEED instruction. But the kernel or CPU have no way of preventing use of RDSEED32, so the kernel developers decided to simply clear the bit, thus telling applications they need to use another method.
Perhaps I am being thick but if this is a motherboard BIOS issue then wouldn’t all kernels be affected and not just the latest one?
It is not a BIOS issue. The issue is that a CPU instruction that is supposed to return a random value can be made to return something not so random. That is a security issue. AMD can fix it via an AGESA update and these are distributed as part of the BIOS. And until that update is applied to a system, RDSEED remains vulnerable.
As a mitigation, the kernel developers have decided to add code to the kernel that removes the CPUID bit for RDSEED on affected systems. This makes it look like the CPU does not support it, which means that applications will not use the vulnerable instruction. What you see in the kernel output is from this code that clears the CPUID bit, the text is quite clear IMO.
HTH
Thank you, @l-c-g
Wanted to share some context I found yesterday:
-
Lenovo’s advisory (based on the one from AMD). You can check if the update/mitigation for your specific machine was released. Whether out yet or not, it will tell you what specifically to look for.
-
Linux Journal article that explains everything in more detail, noob-friendly.
-
I called Lenovo yesterday. They confirmed that the the latest BIOS update from November 11 was for Windows only, and the latest AMD update was also for Windows only. For my machine specifically, obviously (T14s Gen 6 Type 21M1,21M2). So, no dice for this issue yet for me.
(Interestingly, the call center I reached only had 1 person who knew Linux, and was unavailable at the time lol).
- Realized yesterday that Lenovo supports firmware updates for Linux via LVFS. The command is
fwupdmgrfor main Fedora releases (non-immutable) here is a handy guide on how to use it.
Stay gold my friends