Thanks for the excellent answer. As a non-cryptographer who can't read crypto code and also can't be bothered to download the Linux sources and find the part where random numbers are generated, this is a much better response than Linus'. "Read the source" isn't a suitable answer even for most technical people. For regular people, it is completely out of the question.
Respectfully, if you can't read the code, you're not really entitled to have opinions about it. Instead, try asking people you trust who can read code what they think.
Although, I should add that there's this API which uses the output of RdRand straight up:
/*
* Get a random word for internal kernel use only. Similar to urandom but
* with the goal of minimal entropy pool depletion. As a result, the random
* value is not cryptographically secure but for several uses the cost of
* depleting entropy is too high
*/
static DEFINE_PER_CPU(__u32 [MD5_DIGEST_WORDS], get_random_int_hash);
unsigned int get_random_int(void)
{
__u32 *hash;
unsigned int ret;
if (arch_get_random_int(&ret))
return ret;
[...]
There's one interesting use of this in the Linux kernel: the output is used for randomization of the address space. So, I suppose we could say that if NSA can predict RdRand then they can predict memory layout and which might enable some sorts of interesting attacks.
As I understood it, TCP sequence numbers also got the direct output of rdrand. In neither case do I think that's meaningful; the needs of both are sub-cryptographic, due to environmental constraints (ie, no matter how high-quality the randomness you feed it, TCP seqnos and executable address space aren't going to be cryptographically random anyways.)
The only use of randomized address space I know is to mitigate other attack vectors (stack smashing and other arbitrary code execution exploits). So it would just make exploiting an other vulnerability easier, it wouldn't be a vulnerability on its own. So it's still a bit far fetched conspiracy-wise as far as I'm concerned.
I think it would be a justified move (in an evil kind of way). Most of the interesting exploits these days need to leverage more than one vulnerability. This kind of thing would give you a marked advantage in penetrating systems, and do so in a non-obvious way without exposing the targets to other attackers. The advantage would be something like 10x, or whatever the difficulty factor is that ASLR adds to the average exploit. It would also be a good match for probabilistic/big picture kind of approach that a big organization can afford to take.
But will owning RdRand give you good enough control over ASLR, that's another question.
>Respectfully, if you can't read the code, you're not really entitled to have opinions about it.
I disagree. That is like saying if you can't read or write English, you shouldn't have a say in a law that affects you. I bet 90% of the users here don't know how MD5 or SHA1 works but when asked they can still recommend you a better cryptographic hash. I think everyone should be entitled to opinions and proper response because there is no such thing as a dumb question when it comes to security.
The law is imposed upon you whether you want it or not. With the kernel you're free to take it or leave it. The core of kernel development is free to listen to people, or not. They do seem to want a pretty deep understanding.
You're free to just fork the kernel and make it work however you wish. In practice nobody does this. When you're sophisticated enough to explain what you want to the high standards team, it is easier to just make your case to that team.
> The law is imposed upon you whether you want it or not. With the kernel you're free to take it or leave it.
Its not always as black and white. There are times when you are forced to use the kernel, maybe a default on your shared hosting that cannot be changed or a restriction put by your team's Administrator for security.
Forking is not the effective answer either, its just not practical, its too complex to maintain and upkeep with the new changes. Like you said, in practice nobody does this. Had this not been the case, we would have seen less whining about PHP's problems and more forks to fix it.
Whether you can follow all the code in random.c (few can), you can probably get through the comments and have a better understanding of how random number generation works in a Linux environment. Start right after the line:
> (now, with legal B.S. out of the way.....)
and continue until your brain hurts, rinse, and repeat. Peck away at a couple functions here and there. This is a really good exercise for most developers.
/*
* This function will use the architecture-specific hardware random
* number generator if it is available. The arch-specific hw RNG will
* almost certainly be faster than what we can do in software, but it
* is impossible to verify that it is implemented securely (as
* opposed, to, say, the AES encryption of a sequence number using a
* key known by the NSA). So it's useful if we need the speed, but
* only if we're willing to trust the hardware manufacturer not to
* have put in a back door.
*/
void get_random_bytes_arch(void *buf, int nbytes)
