Hacker News Reader

Comment by drewg123 | Hacker News Reader

I'm not sure why you're being downvoted, I had the same reaction. CPU microcode is updateable by the kernel at boot.

On Ubuntu, he'd want to use the amd64-microcode package: https://launchpad.net/ubuntu/+source/amd64-microcode

The bug in question does seem to have stopped some Linux systems from booting, which would of course prevent the update.

Although in the author's case, he seems to be waiting on a BIOS fix because the microcode fix doesn't actually work. In the updates he mentions being told "...that the amd64-microcode package... would fix the issue. This, too, is not the case; the amd64-microcode and intel-microcode packages are both installed by default on all Ubuntu 19.10 systems, including the one I'm experiencing the RDRAND failure on."

It's good news that microcode fixes generally don't demand BIOS updates, but in practice this one seems to be getting fixed that way before it's fixed by the manufacturer.

Although in the author's case, he seems to be waiting on a BIOS fix because the microcode fix doesn't actually work.

That's as well my understanding of the situation => does anybody have more infos?

I was really about to upgrade from an i7-8700 to a Ryzen 3700X but after reading this I froze and now I feel totally insecure... .

EDIT: was answered by "iforgotpassword"

I have a 3700x system (but running Windows) at home. Check with the motherboard vendor first? My board¹ has received three or four updates since I got it (which .. is an entirely different can of worms and doesn't exactly inspire confidence yet). At least they do seem to propagate things "quickly" I guess..

①: https://www.gigabyte.com/Motherboard/X570-GAMING-X-rev-10/su...

This assumes that you can boot.

well, first thing on my list if I can't boot; good 'ol USB live boot to read dmesg and syslog.

Which a live boot, you can install packages such as microcode updates.

This is a microcode bug which causes a kernel to hang. So simply booting from a different medium is not going to help you.

You'll need to compile a kernel which does not depend on the RDRAND instruction as a source of randomness.

It causes systemd to blow up, but you could try doing your microcode update from initrd. Or just get rid of systemd, run your microcode update, and make some Halloween jello shots to take to the no-systemd party (it's going to be even crazier, this year).

If the kernel itself doesn't boot, installing the microcode package may not help. It only helps if the problem only occurs after the point at which the kernel loads the microcode. Hopefully that's early enough for most cases.

Early load microcode updating happens very early for this precise reason.

Indeed. At least the Intel driver does it so early in the boot process that the "microcode updated" message is literally the first line in dmesg on a couple of systems I've bothered to check.

He could boot. His problem was lockups after boot with wireguard directly calling RDRND & looping on non-random random numbers rather than using an API to get random numbers.

The issue is that Linux’s kernel-only “fast” CSPRNG is just thin wrapper around arch_get_random() (ie. RDRAND) when it is supported.

I believe AMD made it policy to stop providing those updates separately and for users to get them via BIOS updates, though I don't have a reference for it right now.

This is a terrible policy because plenty of BIOS vendors couldn't be more apathetic

There appears to be an AMD microcode update [1] in the kernel's linux-firmware repo as recently as 1 week ago, so I don't think this is true? And it's an update for "processor family 17h", which is Zen/Zen2, so it's not like this is only for old CPUs.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

Reply on news.ycombinator.com