I am on ArchLinux (Omarchy) and since recently I see this when booting:
RDSEED32 is broken. Disabling the corresponding CPUID bit.
I see it on both my FW13 (AMD Ryzen AI 9 HX 370) and FW Desktop (AMD RYZEN AI MAX+ 395) and it is announced in the AMD security bulletin: RDSEED Failure on AMD “Zen 5” Processors
I guess we should be seeing firmware update coming soon?
I heard about that problem a few days ago. Not sure that a firmware update could do anything about it though, the problem isn’t in the firmware, so far as I can tell.
You are right. They will most probably not be able to fix entropy problems with microcode… I guess they will simply disable it so that at least kernel will not have to “handle” it.
Will be mitigated with this microcode update : Making sure you're not a bot!
I, unfortunately, have similar problems.
After the last update, the latest kernel option in grub, the luks promt does not show the dots when entering, but recognizes the input and boots, but after a second of seeing the cursor the screen stays black and only shows a blinking underscore.
The other two kernel options show the dots when typing the luks password, but after that the screen stays blank.
This is very unfortunate, because I am not able to update/mitigate the issue.
The rescue kernel option does not work currently, because root account is locked.
I probably have to reset the root password with a live CD.
The grub parameter discussed in the fedora forum did not resolve the issue (edited via grub).
Is there any other known mitigation I could try?
Edit:
Forgot my hardware details:
Device: Framework Laptop 13 AMD AI 7 350
BIOS: Version 3.04 (latest available version)
OS: Fedora 43
Now I am a bit confused. I did try accessing the shell again and could get it to work but I cannot log in with my credentials. I checked the keyboard layout and the username with a live usb to confirm that I am not going crazy.
After quite a bit of debugging, this update somehow did break multiple things on my machine.
The issues I am facing currently should not be relevant for other users.
The firmware update is already available. If it’s missing, file a bug with your distro to update.
Did you ever sort it? My issues are almost identical - no matter the kernel I choose, I can never manage to boot to a working system. First option doesn’t show the dots in the luks prompt, but as soon as I enter the password, the screen changes to minimum brightness and then booting continues, but then I am stuck on a blank screen.
Other options show me the the dots, but same result, screen dims and I boot to a blank screen.
Any advice for recovery?
Yes, but I encountered a completely different issue, that was the culprit all along.
The “RDSEED32 is broken” error you see, had only the side effect of not seeing the dots when promted for the LUKS password.
The primary issue I had was a conflicting file within a package (gnutls) I had installed in both 64bit and 32bit for wine.
I do not know how the update workflow from the GUI package manager and terminal differs, but the update seems to have encountered an error after the restart required by the update and left my system in a broken state.
After you decrypt your system at boot, you should be able to open the terminal with: Ctrl+Fn+Alt+F3
If you need to use the function key depends on your system settings.
Then you can log in with your user account in the terminal and run the update via terminal.
I did need to use a live usb to fix my password for some reason, but I strongly suspect this is a me problem and should not be an issue for others.
There’s a whole thread in the Fedora forums about this right now:
Has Framework commented on this issue at all? Apparently it’s a pretty serious security vulnerability in its current state. Seems to primarily be an issue with AMD.
What makes you think it’s serious? Have you managed to reproduce a statistically relevant number of false 0’s? Because I’ve personally tried with both 16 and 32 bit returns while I drained entropy and do so and I can’t.
Nonetheless, it’s already mitigated by the kernel (it disables rdseed feature from userspace) and it’s fixed already in linux-firmware.
File a bug with your distro to update the firmware if you’re seeing this message.
This article describes it as a “high severity security vulnerability,” so that’s as much as I know.
I’ve helped troubleshoot/file 3 different bugs this week (Fedora or GNOME related) so am a bit bugged out right now 
Seems like there’s plenty of discussion on that Fedora thread though so hopefully a fix is on the way.
It’s high-severity for anyone using the raw RDSEED32 system, but the Linux kernel only uses it as one of a number of pieces of the data that it mixes in to create the /dev/randomand /dev/urandom system. So anyone using Linux is insulated from it, even before it was disabled. I haven’t looked into what Windows might do with it, it could be more of a problem there.
The Linux kernel doesn’t even use 32 bit returns of rdseed. It only uses 64 bit.
Sorry, it’s not easy to find the actual source code for that (and I haven’t actually managed it, though I don’t doubt the information as it makes more sense). I was going by general information about /dev/random and /dev/urandom.
Is there any news of the BIOS updated with the AGESA that fixes this issue?