3 ms·

AMD Releases BIOS Fix for Booting Newer Linux Distributions

8 points by jjuhl 7y ago

johnklos 7y ago
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.
- jameshilliard 7y ago
  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/1c53d4a070edbec8ad2d384ba0014d0eb6bae077 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-509418688 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-in-it-hangs-until-crng-init-done https://unix.stackexchange.com/questions/442698/when-i-log-i...
  - nwmcsween 7y ago
    So they can't use AT_RANDOM to either seed a prng or just use it directly?
- tssva 7y ago
  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.

8 points by jjuhl 7y ago

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.

jameshilliard 7y ago
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/1c53d4a070edbec8ad2d384ba0014d0eb6bae077 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-509418688 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-in-it-hangs-until-crng-init-done https://unix.stackexchange.com/questions/442698/when-i-log-i...
- nwmcsween 7y ago
  So they can't use AT_RANDOM to either seed a prng or just use it directly?
tssva 7y ago
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.