Comment by zaroth
7 years ago
Sounds like a bit of code which was hard to trigger the negative test and therefore the fallback failed to work properly.
Not sure how the kernel devs generally go about testing the “this virtually never happens” code paths without adding debug switches to every unhappy path.
Certainly I doubt they are using DI/IoC to wrap an interface to RDRAND which allows unit testing the failure modes.
At least the result is a failure to generate a key, not a compromised key.
> 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.
That "security engineer" appears to imply we use rand() to create crypto keys. I am not sure what he has been smoking. We don't. He appears to be just somebody who doesn't research very well...
And no. We do no generate "keys" from either rand(), nor from RDRAND. We use RDRAND for uuid generation, and rand() for seeding hash tables if there's no better source of entropy. That's all.
Jeezuz christ.
I mean, if we seed hash tables, which options do we have? getrandom()? that either blocks (sometimes very long in virtualized envs) or fails during early boot (and systemd runs in earliest boot being the first process to launch), when the random pool is not initialized. /dev/urandom? That logs loudly about any use when the pool is not initialized. So yeah, we opted to first use RDRAND if available, then fall back to getrandom() with GRND_NONBLOCK, and finally to plain rand() if neither of that works. That has everything we need: doesn't delay boot forever. Doesn't cause log messages about us using a non-initialized pool. It potentially gives us crappy seeds for the hashtable initially, but given that we reseed when we see too many collisions and then getrandom() actually works correctly, we should be fine.
Anyway, you can stick that "security engineer" somewhere, that smug, unresearched bitching on Twitter is just annoying.
Lennart
Filippo Valsorda said nothing about keys. Xe did not mention them at all.
1 reply →
UUIDs and hash table keys are probably what they meant by "keys".
The 'edit-compile-run-debug' cycle is so expensive, chip design is all about simulation.
Chip vendors, and the tools they use to design them, actually do a significant amount of work for error cases. This is important not just for correctness, but for production yield, reliability, temperature and radiation hardness, etc. As chips get larger and more dense this becomes more and more important.
Single Event Upset (where one bit flips) is an example of the type of error. https://en.wikipedia.org/wiki/Single_event_upset
Virtual machines perhaps.