Some AMD CPU's RDRAND might not return random data after a suspend/resume

Re:Some AMD CPU's RDRAND might not return random data after ... by loeg on Tuesday May 07, 2019 @06:39PM (#19854087)

> Sounds like a bit of code which was hard to trigger the negative test and therefore the fallback failed to work properly.

No; it turns out that's giving systemd too much credit (sadly). See [1].

The problem appears to be that RDRAND was signalling success, but producing a nonrandom value. This is bad and a violation of the specification.

Can't speak to Linux kernel development, and in this particular case, that isn't the problem.

The linked bug involves systemd using the world's worst random number generator. A security engineer goes into more detail on this twitter thread[1]: https://twitter.com/FiloSottile/status/1125840275346198529 (or unrolled: https://threadreaderapp.com/thread/1125840275346198529.html?... ).

> At least the result is a failure to generate a key, not a compromised key.

In fact, the result is a compromised key -- the bug report is due to colliding "globally unique" identifies generated through a flawed random gathering process.

[ Parent | on HN ]

[dead]

Re:Some AMD CPU's RDRAND might not return random data after ... by JdeBP on Wednesday May 08, 2019 @08:01AM (#19858003)

Filippo Valsorda said nothing about keys. Xe did not mention them at all.

[ Parent | on HN ]

Re:Some AMD CPU's RDRAND might not return random data after ... by zaroth on Wednesday May 08, 2019 @03:49PM (#19862230)

The linked bug report showed errors using OpenSSL to generate keys after resume on an AMD platform. It seemed to indicate RDRAND returning an error code instead of entropy.

Sorry for any confusion.

[ Parent | on HN ]

Re:Some AMD CPU's RDRAND might not return random data after ... by nitrogen on Tuesday May 07, 2019 @09:55PM (#19855250)

UUIDs and hash table keys are probably what they meant by "keys".

[ Parent | on HN ]