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

[rene]

Not on distros using the latest kernel, bro.

Server silicon will be shipped months from now, after the consumer hardware has done "beta testing" for it.

Apparently, the "consumer" hardware is part of the testing process to save some buck.

You can run bash on Windows too, although you are most likely going to be writing C or even assembler for the test themselves.

say someone how close to the matter? again, had they just one intern trying random OS' this would not have even made it out to the market. What makes matters worse that this instruction appears to return fixed 0xffffffff which makes one wonder what formal verification or other automated testing they had in place for this instruction (aka none?). What makes the whole case absolutely hilarious is that there was a similar 4+ years old bug already opened on the linux kernel bugzilla that is potentially still not fixed? So much for "they reacted quickly" https://bugzilla.kernel.org/show_bug.cgi?id=85911

[rene]

outside of your fantasy world systemd did use /dev/random and had stalled boots waiting for entropy in some cases, which were fixed by usage of rdrand. urandom is pseudorandom, you don't need any kernel or hardware help for that, so even bringing it up here is incredibly clueless. and btw what makes you think kernel doesn't use rdrand? /dev/random doesn't grow on trees, it has to be implemented somehow and modern kernels do use rdrand

so, what is so important in systemd that it needs more then urandom early in the boot?

[nranger]

AMD should work fast. Zen 2 is selling very, very well. See the lines at MicroCenter the morning of the release.

Hey that's the Microcenter in St Louis Park MN. I got my FX-8350 (among other parts) over the years there... good times... good times...

[Britoid]

so, what is so important in systemd that it needs more then urandom early in the boot?

high chance of getting two of the same value and you don't want two instances having a chance of the same instance id.

/dev/urandom isn't ready that early in the boot process.

[F.Ultra]

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.

Or perhaps they tested the instruction and it works but then the needed initialization was somehow never shipped to the production firmware for the BIOS or the production BIOS where changed later in the chain. Or is this confirmed to be a bug in the CPU and not in the BIOS?

[tildearrow]

high chance of getting two of the same value and you don't want two instances having a chance of the same instance id.

/dev/urandom isn't ready that early in the boot process.

Really? Couldn't they use a different method to allocate instance IDs?

[oiaohm]

so, what is so important in systemd that it needs more then urandom early in the boot?

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

The reason is stated in the above file. Hash table seed generation is a security mitigation. You need a randomish value for that mitigation. UUID generation in places randomish value helps. Both of these are need before the kernel number generator will be functional.

I do think systemd does need to have it messages to end users made clearly when its having RDRAND issue and maybe a count out ie try 20 times to get RDRAND to work then call it. I would say panic and stop with a clean message with a kernel boot flag added to say hey this platform has RDRAND it busted don't use it.

EOPNOTSUPP option say that systemd at least if it believe the system does not have a RDRAND can find it way forwards.

Remember RDRAND not working can lower the quality of your TLS encryption and other things so if RDRAND is broken. You really do want to know about as RDRAND failure will undermine hash table security and other security things.

[nuetzel]

As much as I love AMD; I would not call no action for 4+ years fast: https://bugzilla.kernel.org/show_bug.cgi?id=85911 Also what is with this bug in previous generation CPUs after suspend / resume?

Hello Rene,

as posted several times here, too:

AMD A4-6210

https://bugzilla.redhat.com/show_bug.cgi?id=1150286

So @Michael:
Please ask AMD about 'older' Ryzen 2xxx and Ax-xxxx, too. Please.
BIOS/firmware updates?

[Guest]

Debian is kernel 4.19. They are essentially on the first rev of 18.04 ubuntu LTS. Those all work atm.

I do not understand what you are saying. Ubuntu disco: systemd v. 240. Debian Buster: systemd v. 241.

[wokkel]

The comments on this thread are so amazingly all over the place I had to register (oh no, someone is wrong on the internet).
On the systemd side: they claim they had to use randr to get randomness during early boot. They need weak randomness (as stated in their code) so not for crypto stuff. They had 2 options that make sense:
1) Use /dev/urandom - No that makes logging messages in the kernel when there is not enough randomness to provide crypto grade random
2) Use a C based random number generator (as has been used since the earliest computers). There are numerous algorithms available.
But instead they used randr which is there to provide crypto grade randomness and have a silly 'if the operation does not do what I like, i keep retrying it". This is called an endless loop. The reason for not using urandom (which is strong enough for what they need randomness for) is plain and utter stupid: logging messages in the kernel are a reason to re-implement something and getting it wrong?

So, systemd choose to use a means to get randomness that is neither fit for purpose (ultrastrong randomness for a mere hash/uuid generation) and got it wrong by doing an endless loop. This last bit is basically a bug on the systemd side. The first is a common theme in systemd where overengineering prevails over common sense.

On the AMD part: sure that is a bug in the randr instruction. Like many CPUs have bugs and most get fixed with new microcode. Nothing new there. Silly but to be expected.

So my take on this is: AMD made a booboo and is correcting it, Systemd is a booboo by design and is just adding silly arguments in code to explain their design.