By: Linus Torvalds (torvalds.delete@this.linux-foundation.org), August 11, 2019 10:05 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 11, 2019 10:43 am wrote:
>
> And notice how we don't actually expose the entropy pool itself. That's just the seed of the randomness
> that gets exposed. The actual random numbers that get exposed are from cryptographic hashes from the pool,
Side note: this is a simplification.
We have several different kinds of randomness. Some people don't need the full cryptographically secure stuff. /dev/urandom already got mentioned: that's still using the secure hash, but the seeding pool it uses doesn't really care about how much entropy it has (even if new data does get continually mixed into it) and you can read it indefinitely.
But some in-kernel users don't do that. They just don't care enough, and have performance requirements that are just much more important than "true cryptographic randomness". So there are interfaces that are explicitly just pseudo-random numbers without any secure hashing at all (because sometimes that's what you want), and there are other interfaces that are just "get a single random word".
Those latter ones can actually get affected by the rdrand bug, because we do assume a certain level of competence there. So you might end up having rdrand affect things like TCP sequence numbers etc (I didn't look). These things may not be "cryptographically secure" things, but they might open you up to things like DoS attacks.
So again - definitely get the microcode update. The HW bug is real and serious. It just isn't necessarily fatal for the basic operations of the kernel, and it doesn't really mean that your keys are likely to be compromised or untrustworthy (if you used the right interfaces to generate them).
Linus
>
> And notice how we don't actually expose the entropy pool itself. That's just the seed of the randomness
> that gets exposed. The actual random numbers that get exposed are from cryptographic hashes from the pool,
Side note: this is a simplification.
We have several different kinds of randomness. Some people don't need the full cryptographically secure stuff. /dev/urandom already got mentioned: that's still using the secure hash, but the seeding pool it uses doesn't really care about how much entropy it has (even if new data does get continually mixed into it) and you can read it indefinitely.
But some in-kernel users don't do that. They just don't care enough, and have performance requirements that are just much more important than "true cryptographic randomness". So there are interfaces that are explicitly just pseudo-random numbers without any secure hashing at all (because sometimes that's what you want), and there are other interfaces that are just "get a single random word".
Those latter ones can actually get affected by the rdrand bug, because we do assume a certain level of competence there. So you might end up having rdrand affect things like TCP sequence numbers etc (I didn't look). These things may not be "cryptographically secure" things, but they might open you up to things like DoS attacks.
So again - definitely get the microcode update. The HW bug is real and serious. It just isn't necessarily fatal for the basic operations of the kernel, and it doesn't really mean that your keys are likely to be compromised or untrustworthy (if you used the right interfaces to generate them).
Linus
