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

[rene]

That's not surprising, what is surprising is that none tested that this CPU instruction actually works at all.

I actually find it surprising that AMD did not test a modern Linux. A major CPU vendor this size certainly should test the second largest OS on their new CPU. Unless they hate systemd as much as others, and only tested non-systemd systems. But then again, they had the same bug after suspend/resume open for older CPUs for over 4 years already, see previous post if approved my moderators, ... PS: aka: https://bugzilla.kernel.org/show_bug.cgi?id=85911 they certainly should have addressed this my now.

[rene]

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

taking a shortcut and not using kernel APIs waiting for enough sanitized entropy is exactly what got them into this issue. What is next? adding all device drivers to systemd because: faster? Ah right, systemd will replace the kernel soon anyway.

[starshipeleven]

I mean, it does work. AFAIK it just "forgets" to store some state that is expected by some software like systemd.

A random number instruction fails to return a random number.

Random people on the internet claim it is "working as advertised" and that it's just systemd that is picky, ignoring that some Windows games also crashed on this platform.

[starshipeleven]

I actually find it surprising that AMD did not test a modern Linux

Why would they. Server distros won't support this hardware for a while, and it's also consumer hardware so it's kind of unlikely to be used with server distros anyway.

I repeat, here the issue is that they didn't test that the fucking instruction itself was working correctly.

[tildearrow]

Typo:

But considering it also has a fix for the Desinty 2 Windows game

[starshipeleven]

taking a shortcut and not using kernel APIs waiting for enough sanitized entropy is exactly what got them into this issue. What is next? adding all device drivers to systemd because: faster? Ah right, systemd will replace the kernel soon anyway.

They did exactly what they should do, they are using less secure sources of entropy for tasks that don't need high security, so they can leave the high-quality entropy for applications that actually need it.

Let's not forget that this instruction was (and still is) marketed as a security feature for secure applications, so it's not just an issue for systemd that uses it as "untrusted source", but it would have done harm to applications that actually trusted it to be safe.

[JPFSanders]

It is so fashionable to hate on systemd isn't?

AMD screwed this one, same as they screwed with the C6 power issue on ZEN1 (is it fixed yet on ZEN2?)

Systemd could have been more clever here? About guessing a CPU instruction won't behave the way AMD published should behave?

Systemd not fixing the issue quick enough? They fixed it months ago, is the distros who didn't adopted the patch.

AMD has issued a bios fix (Smoking gun that they screwed) yet Systemd is responsible...

Clearly systemd is the bane of the computing world, the "canadian devil" incarnated (South park reference BTW)...

This is so tiresome. (Chinese man reference from "empire of dust")

[Britoid]

Even if they didn't test booting Linux, you'd think AMD would have some sort of tests in place to test their CPUs?

[JPFSanders]

Even if they didn't test booting Linux, you'd think AMD would have some sort of tests in place to test their CPUs?

AMD is not stupid, CPUs are complex, rushing for deadlines sometimes lead to issues like these, I'm sure there are more bugs lurking down there, it happens to Intel/ARM too every now and then.

The issue is that both Systemd and AMD have done their part and identified and fixed the issue.

The only people pointing fingers and making a fuss are the "it is all Systemd's fault" chaps.

I'm very happy with both AMD and Systemd's handling of the matter, but I guess some people can't be pleased.

[rene]

Why would they. Server distros won't support this hardware for a while, and it's also consumer hardware so it's kind of unlikely to be used with server distros anyway.

I repeat, here the issue is that they didn't test that the fucking instruction itself was working correctly.

why? because: 1) ~2nd largest market share 2) server silicon will be mostly identical anyway 3) hundreds of millions if not billion $$$ investment - you want to test it with everything at hand to make sure you do not screw this up 4) nicer to test and script than WinDOS anyway