A months-old AMD microcode bug destroyed my weekend

Re:A months-old AMD microcode bug destroyed my weekend by viraptor on Tuesday October 29, 2019 @08:15AM (#21386256)

> 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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by iforgotpassword on Tuesday October 29, 2019 @02:45PM (#21390665)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by zepearl on Tuesday October 29, 2019 @05:57PM (#21392535)

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?

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by Dylan16807 on Tuesday October 29, 2019 @05:59PM (#21392555)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by zepearl on Tuesday October 29, 2019 @06:06PM (#21392602)

Thx :(

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by dfox on Tuesday October 29, 2019 @10:49PM (#21394250)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by drewg123 on Tuesday October 29, 2019 @08:22AM (#21386293)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by Bartweiss on Tuesday October 29, 2019 @02:06PM (#21390242)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by zepearl on Tuesday October 29, 2019 @05:32PM (#21392297)

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"

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by darklajid on Tuesday October 29, 2019 @09:55PM (#21393956)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by amelius on Tuesday October 29, 2019 @08:32AM (#21386374)

This assumes that you can boot.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by drewg123 on Tuesday October 29, 2019 @09:56AM (#21387181)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by dfox on Tuesday October 29, 2019 @10:53PM (#21394273)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by cremp on Tuesday October 29, 2019 @08:44AM (#21386477)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by LeonM on Tuesday October 29, 2019 @09:44AM (#21387032)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by ehvatum on Tuesday October 29, 2019 @01:26PM (#21389713)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by pedrocr on Tuesday October 29, 2019 @09:44AM (#21387035)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by nemetroid on Tuesday October 29, 2019 @01:30PM (#21389765)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by throwaway8941 on Tuesday October 29, 2019 @01:50PM (#21390018)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by swills on Tuesday October 29, 2019 @09:47AM (#21387078)

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.

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by thenewnewguy on Tuesday October 29, 2019 @11:23AM (#21388177)

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

[ Parent | on HN ]

Re:A months-old AMD microcode bug destroyed my weekend by throwaway2048 on Tuesday October 29, 2019 @09:52AM (#21387131)

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

[ Parent | on HN ]