AMD Releases BIOS Fix To Motherboard Partners For Booting Newer Linux Distributions

[numacross]

New BIOSes also contain AGESA fixes that allow faster and higher boosts for Zen 2. This has brought noticeable gains on Windows.

[milkylainen]

Great, so a bunch of the Systemd bashing over this was completely unfounded and even AMD themselves acknowledged this as a bug.

How do you know this is an AMD bug? Clearly somebody did not bother to read the architecture manual.
So maybe AMD decided that it was no harm in changing the behavior to permit stupid software to work?
Since there are no intricate details to the "fix", naming this as a bug-fix is slightly overzealous.
Behavior-fix perhaps? Who knows.
It wouldn't be the first time hardware adapts to software although the way more common case is the other way around.

[Danny3]

OK, it's not systemd's fault, but can't systemd be smart enough to fallback to another thing if the CPU doesn't have this function or it's broken?
I understand that it's for security, but making the whole system unbootable is insane when the processor has this kind of problem.
The systemd developers they should still put a fallback with probably longer boot time or a bit less security instead of just stopping the whole boot process.

[rene]

How do you know this is an AMD bug? Clearly somebody did not bother to read the architecture manual.
…

No, while not pretty, systemd checks the return value. While I do not have such an AMD CPU yet, the reports clearly indicate the rdrand instruction does not return a random value on success, but always 0xffffffff which is clearly not random. I agree however, that systemd should not try to re-implement the kernel's job and instead just use /dev/{u,}random as the Linux kernel already mixes and sanitizes not as random values. I'm actually more disappointed that AMD did not caught this obvious bug during development, especially as they had a similar bug open since around 2014 for previous CPUs after suspend / resume, ..! :-/ https://www.youtube.com/watch?v=RoyxwkglSUY

[Venemo]

Does this mean that during the development of the Zen 2 products, there was not a single person in AMD who actually booter a newer Linux distro to see if it works with the new chip?

[Serafean]

OK, it's not systemd's fault, but can't systemd be smart enough to fallback to another thing if the CPU doesn't have this function or it's broken?
I understand that it's for security, but making the whole system unbootable is insane when the processor has this kind of problem.
The systemd developers they should still put a fallback with probably longer boot time or a bit less security instead of just stopping the whole boot process.

1) There is a fallback if the CPU doesn't have this instruction. Look around have_rdrand
2) Where would you put the line? At some point you have to trust that stuff works according to the docs, or do you suggest that around every mov() instruction there is a workaround "just in case it doesn't work"?

Also making a system unbootable when the processor has a problem might be the better outcome in some cases.

[starshipeleven]

I wonder: do mobos get OTA updates? Like, if there's a mobo sitting in a box in a warehouse that I could buy right now, would it get the new BIOS that precludes the problem? Because, otherwise... :C

I'm not sure what is the problem. The only way to update motherboards is to boot them into their own UEFI and provide the firmware on a USB drive.

This bug does not affect the motherboard UEFI, so you're fine.

[starshipeleven]

I'm assuming that this might also be fixable via updated microcode in the kernel/initrd...

Maybe, or maybe not. If this is an issue in the board bringup firmware (and it might very well be) you can only hope the OEM releases a new firmware with the fix.

[schmidtbag]

I guess it's good they figured this out now while not too many people got their hands on Zen2, let alone Linux or Destiny 2 users.

[michich]

systemd should not try to re-implement the kernel's job and instead just use /dev/{u,}random

A long comment in the code explains why it's not that simple:

https://github.com/systemd/systemd/blob/f90bcf8679e8708788290519dc09371e60c6fc82/src/basic/random-util.c#L34