5 ms·

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

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 https://launchpad.net/ubuntu/+source/amd64-microcode

amelius 7y ago
This assumes that you can boot.
- deleted 7y ago
  [deleted]
- cremp 7y ago
  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.
  - LeonM 7y ago
    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.
    - ehvatum 7y ago
      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).
  - pedrocr 7y ago
    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.
    - nemetroid 7y ago
      Early load microcode updating happens very early for this precise reason.
      - throwaway8941 7y ago
        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.
- drewg123 7y ago
  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.
  - dfox 7y ago
    The issue is that Linux’s kernel-only “fast” CSPRNG is just thin wrapper around arch_get_random() (ie. RDRAND) when it is supported.
swills 7y ago
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.
- throwaway2048 7y ago
  This is a terrible policy because plenty of BIOS vendors couldn't be more apathetic
- thenewnewguy 7y ago
  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/linux-firmware.git/commit/?id=2b016afc348ba4b5fb2016ffcb2822f4a293da0c https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
Bartweiss 7y ago
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.
- zepearl 7y ago
  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"
  - darklajid 7y ago
    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/support#support-dl-bios https://www.gigabyte.com/Motherboard/X570-GAMING-X-rev-10/su...

amelius 7y ago

This assumes that you can boot.

deleted 7y ago
[deleted]
cremp 7y ago
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.
- LeonM 7y ago
  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.
  - ehvatum 7y ago
    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).
- pedrocr 7y ago
  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.
  - nemetroid 7y ago
    Early load microcode updating happens very early for this precise reason.
    - throwaway8941 7y ago
      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.
drewg123 7y ago
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.
- dfox 7y ago
  The issue is that Linux’s kernel-only “fast” CSPRNG is just thin wrapper around arch_get_random() (ie. RDRAND) when it is supported.

swills 7y ago

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.

throwaway2048 7y ago
This is a terrible policy because plenty of BIOS vendors couldn't be more apathetic
thenewnewguy 7y ago
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/linux-firmware.git/commit/?id=2b016afc348ba4b5fb2016ffcb2822f4a293da0c https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

Bartweiss 7y ago

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.

zepearl 7y ago
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"
- darklajid 7y ago
  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/support#support-dl-bios https://www.gigabyte.com/Motherboard/X570-GAMING-X-rev-10/su...