Hacker News Reader

Comment by viraptor | Hacker News Reader

> When there's a bug in the CPU microcode, you're at the mercy of your motherboard vendor to release a new system BIOS that will update it for you

That's just... not true. Is the article wrong, or was the rdrand issue actually bios-specific rather than in CPU microcode?

Edit: Whoever downvoted this - ucode update is supported by both Intel and AMD for quite a while. You certainly can just download it: https://github.com/platomav/CPUMicrocodes/tree/master/AMD

View on HN

The bug is in the initialization part of the microcode and can only be patched during CPU initialization by the bios. Early microcode loading by the kernel is too late.

In the worst-case scenario of a lack of motherboard-update, to make things work during boot and later in Linux would it be enough to disable RANDOM_TRUST_CPU in the kernel source config ( https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.... ) (and/or using a kernel parameter in Grub), or would that make it unavailable only to the kernel itself but still available to other programs (e.g. systemd, wireguard, etc...)? If #2, are there any other parameters to completely disable it to then make programs fallback to kernel-based sources of entropy (disk activity, network, etc) to generate their random nbrs?

#2, as the article says. And no, unless you count running a hypervisor to hide the instruction.

Thx :(

get_random_u32() which is the function in question uses RDRAND if ut is available regardless of what RANDOM_TRUST_CPU says. It is meant of fast source of “good enough entropy” for short lived secrets. Short circuiting to RDRAND arguably breaks the API contract, but when RDRAND actually produces random-ish values it is probably good enough.

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

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...

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...

Reply on news.ycombinator.com