These barnd new chips look really attractive. Unfortunately, most resent Linux distros fail to boot on them. Debian 10 is apparently OK. The central problem is (another!) bug in AMD's implementation of the rdrand instruction. This shows up because systemd 240 and later tries to actually use rdrand. systemd 243 has code that works around the AMD bug. Apparently Fedora 30, ubuntu 19.04, and other systemd-using distros' installation media have systemd versions that are affected. I first saw this on phoronix: <https://www.phoronix.com/scan.php?page=article&item=ryzen-3700x-3900x-linux> but I think that this is a better writeup: <https://linuxreviews.org/AMD_Ryzen_3000_series_CPUs_can%27t_do_Random_on_boot_causing_Boot_Failure_on_newer_Linux_distributions> Note: I have no first-hand experience so I cannot vouch for the details.
Here's the commit that lets systemd survive the AMD rdrand bug. The comments are interesting too. <https://github.com/systemd/systemd/pull/12536/commits/1c53d4a070edbec8ad2d384ba0014d0eb6bae077>
On Tue, 9 Jul 2019 at 12:14, D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
Here's the commit that lets systemd survive the AMD rdrand bug. The comments are interesting too.
< https://github.com/systemd/systemd/pull/12536/commits/1c53d4a070edbec8ad2d38...
This sure seems to point at rdrand being a scary feature to consider using. I imagine that it would be better to access /dev/urandom or /dev/random, and have those facilities mix rdrand in somewhat, if possible. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
| From: Christopher Browne via talk <talk@gtalug.org> | This sure seems to point at rdrand being a scary feature to consider using. I put the blame squarely on AMD. They've botched rdrand a couple of times. It's not really our job to wonder if instructions aren't implemented correctly. Imagine if FDIV didn't work? Whose problem would that be? | I imagine that it would be better to access /dev/urandom or /dev/random, | and have those facilities mix rdrand in somewhat, if possible. In this case, not really. Read the comments in the code (not the commit): <https://github.com/systemd/systemd/blob/master/src/basic/random-util.c> rdrand is suspect for another reason. We have no way knowing if rdrand has hidden structure. Such a compromise would amount to a backdoor into most crypto. But systemd folks say that their application of the output of rdrand doesn't need strong random numbers.
On Tue, Jul 9, 2019 at 3:09 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: Christopher Browne via talk <talk@gtalug.org>
| This sure seems to point at rdrand being a scary feature to consider using.
I put the blame squarely on AMD. They've botched rdrand a couple of times. It's not really our job to wonder if instructions aren't implemented correctly. Imagine if FDIV didn't work? Whose problem would that be?
| I imagine that it would be better to access /dev/urandom or /dev/random, | and have those facilities mix rdrand in somewhat, if possible.
In this case, not really. Read the comments in the code (not the commit):
<https://github.com/systemd/systemd/blob/master/src/basic/random-util.c>
rdrand is suspect for another reason. We have no way knowing if rdrand has hidden structure. Such a compromise would amount to a backdoor into most crypto. But systemd folks say that their application of the output of rdrand doesn't need strong random numbers.
Using logic alone, not being at all knowledgeable re: this level of programming, I will state that that opinion is absolutely pathetic! Using poor tools gives a greater surface for hacker attacks and not trying to minimize that - - - - well I consider that a Microsoft trait but then I don't benefit from the billions spent upon computer security like Microsoft does so maybe I'm wrong! Regards
participants (3)
-
Christopher Browne -
D. Hugh Redelmeier -
o1bigtenor