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.
Sorry for any confusion.
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
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.