AMD Releases BIOS Fix for Booting Newer Linux Distributions | Hacker News Reader

AMD Releases BIOS Fix for Booting Newer Linux Distributions

phoronix.com

8 pointsjjuhl4 comments

This really should be fixed in systemd.

First, randomness should be done in the kernel, not in systemd.

Second, we should have a choice about whether to use hardware-based randomness or not.

Third, any failure to boot due to randomness is just inherently broken. I would LOVE to have someone explain to me how any system that even has the possibility of not booting because of a random number generator is in any way correct or desirable.

Well systemd did add a workaround but it's pretty hard to fault them here since their original implementation followed the RDRAND spec:

https://github.com/systemd/systemd/pull/12536/commits/1c53d4...

Systemd does not have its own random number generator:

https://github.com/systemd/systemd/issues/11810#issuecomment...

  > No, let's not roll our own PRNGs, we don't want to maintain that. it's fine to use the CPU RNG, the kernels or glibc's, but I don't want to maintain our own version in our codebase, sorry.

There are good reasons for using RDRAND for UUID generation since it's required very early during boot often before the kernel's random pool is filled. This sort of issue is especially common on embedded systems, I've had to use haveged to fill the kernel entropy pool otherwise many applications don't startup properly.:

https://unix.stackexchange.com/questions/442698/when-i-log-i...

So they can't use AT_RANDOM to either seed a prng or just use it directly?

The kernel doesn't have enough entropy to provide sufficiently randomness at the point the call is made.

RDRAND is a cpu opcode. Systend should be just as able to depend upon it as it is upon the JMP instruction working. This is an AMD bug and failure period.

Reply on news.ycombinator.com