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

[Wielkie G]

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

As far as I understand, not only logging messages but also possibly hanging until more more randomness is generated. Or is it just the getrandom() syscall?

2) Use a C based random number generator (as has been used since the earliest computers). There are numerous algorithms available.

How would you seed such an algorithm? I believe rdrand is used specifically for that purpose. Though rdtsc + the current CPU number might have been enough for a pretty good seed.

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

Where did you read that? From a quick look at systemd sources, the operation on Zen 2 CPUs did succeed so it was not being retried - it just always returned the same "random" number. In fact, systemd never repeats the rdrand instruction, even when it fails.

And what is wrong with using a CPU instruction if it is available? Should AESNI also be banned as it might be buggy on some CPU created in the future? If rdrand was only meant to be used by the kernel it would be a privileged instruction.

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.

Oh, I believe AMD needs a lot more bashing than it currently receives. This is a major bug in a supported x86 instruction, which should have been caught by the validation team. It seems like the validation has been significantly reduced for Ryzen 3000, hopefully it will catch up for EPYC 2 release or AMD will be even more ridiculed...

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.

[josh_walrath]

It is so fashionable to hate on systemd isn't?
This is so tiresome. (Chinese man reference from "empire of dust")

That movie was so sensationally racist.

The comments on this thread are so amazingly all over the place I had to register (oh no, someone is wrong on the internet).

My version of this was someone saying Linux sucks.

And they're not even wrong.

[ThoreauHD]

I'm wondering if this affects the UEFI, if it's linux based.

[F.Ultra]

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.

Congrats on being mentally stuck on the "No that makes logging messages in the kernel". For any one else interested that particular issue came up via a bug report to systemd and the discussion there gives out more information: https://github.com/systemd/systemd/issues/4167

[Danny3]

it can and such fallback was implemented as soon as such misbehaviour of amd rdrandr was discovered.
or you asked whether systemd should be able to predict any possible future misbehaviour in any possible future cpu? no, systemd doesn't have crystal ball

Ok, it's good that they implemented a fallback, but they should learn something from this.
Systemd is the second most important part after the kernel from a distro building blocks and should try the make sure that it will not stop unless it's really something very very very important missing and only in that case shold stop the booting process.
Since systemd is so important now nothing else works if it doesn't work.
They don't need a crystall ball, but they can check if the processor has some feature they want to use first and if the processor doesn't have it or it's broken, they could implement a fallback for it and put some message in the log file, but don't break the whole boot process because they want to use a nice to have feature and they can't.
"With great power comes great responsibility" - Spiderman
I hope that th systemd developers understand now that they've made a very important piece for the Linux distro and they have a big responsibility to take care also about this unfortunate cases where is not directly their faul, but they can do something about it even for the future cases that might come.

[leipero]

IMHO the vendors should disclose technical details of bugs in general, and especially of such security sensitive instructions specifically. How should we trust such CPUs without understanding what is going on here? https://www.youtube.com/watch?v=RoyxwkglSUY

Well, you can NEVER trust complex/any proprietary hardware/software, if you do, then you are naive. I personally do not see a valid reason for proprietary hardware/anything, even software 'art' such as games (they get cracked anyway). To make things worse, I am very positive (I'm sure) that developers of proprietary software use free software and do not disclose it's usage most of the time, especially smaller developer teams.
This is not only unjust and unfair for 'consumers' but also for developers working on free software.

[leipero]

To troll a bit, systemd is awesome . And seriously, I think it's awesome.
AMD is at fault here (from what I got from all posts if it wasn't obvious UEFI fix), and I say that as 'AMD fanboy', you have to be ralistic, no matter how much you might hate systemd, if something should function in specific way on hardware level, and it doesn't, blaming the software for it is ridicilous.

[ozbird]

It's great that AMD has (presumably) fixed these issues quickly.

However, the real test is how quickly board manufacturer release an updated BIOS with the fixes incorporated to users.

[Hugh]

Ok, it's good that they implemented a fallback, but they should learn something from this.
Systemd is the second most important part after the kernel from a distro building blocks and should try the make sure that it will not stop unless it's really something very very very important missing and only in that case shold stop the booting process.

I want lots of problems checked for. Even "impossible" ones, within reason. This was an impossible one.

But coding a workaround for each impossible one multiplies the complexity of handling something that won't come up. And complexity is a breeding ground for bugs and for maintenance burden. I think that they probably made the right decision.

Not everyone agrees with me, but I think that stopping when things are inconsistent rather than ignoring the problem is a good idea. Sometimes motoring through gets the right result, sometimes not (usually without the user knowing).

So: what do you think they should learn? Why do you think that you know more than they do? Show some humility! It's not that suggestions are rude, but ones that don't reflect the context properly are not useful.

Since systemd is so important now nothing else works if it doesn't work.
They don't need a crystall ball, but they can check if the processor has some feature they want to use first and if the processor doesn't have it or it's broken, they could implement a fallback for it and put some message in the log file, but don't break the whole boot process because they want to use a nice to have feature and they can't.

There is a well-defined test for the feature and systemd does test for it. Correctly. Exactly as you are desiring.

As far as testing for broken features, that only make sense when particular bugs are known. Again, systemd now checks for this AMD bug. But that was only added when this bug (or a similar one) was discovered. Otherwise you certainly are demanding a crystal ball.

"With great power comes great responsibility" - Spiderman
I hope that th systemd developers understand now that they've made a very important piece for the Linux distro and they have a big responsibility to take care also about this unfortunate cases where is not directly their faul, but they can do something about it even for the future cases that might come.

Please be specific here. Are you requesting that the handle all imaginable hardware bugs? Like 2 + 2 yielding 5?

[pal666]

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

so what is precluding you from reading source comment?