By: Gionatan Danti (g.danti.delete@this.assyoma.it), August 11, 2019 2:12 pm
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on August 11, 2019 11:05 am wrote:
> 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
Very nice write-up.
Thanks.
> 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
Very nice write-up.
Thanks.
