Question: I was recently discussing the issue of RDRAND in Intel chips and the whole issue about how NSA could potentially be influencing Intel to weaken or create backdoors in their design. 

This [petition](https://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4) was posted asking Linus Torvalds to ignore RDRAND and not include it as a source of entropy in `/dev/random/`. You can see Linus' response [here](https://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4/responses/9066). 

My main question is, would using RDRAND as one source of entropy (amongst many others) potentially compromise the 'randomness' of `/dev/random` by adding some predictability? Or is he correct in saying that It really does not make any difference as long as its not the only thing entropy is generated from?

Answer: 
The way in which RDRAND's output is mixed into the /dev/random output buffers 

```
    linux drivers/char/random.c, extract_buf()

    /* ... compute a hash.l[i] PRNG ... */
    /*
     * If we have a architectural hardware random number
     * generator, mix that in, too.
     */
    for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
            unsigned long v;
            if (!arch_get_random_long(&v))
                    break;
            hash.l[i] ^= v;
    }
    /* ... pass hash.l to userspace ... */

```

seems vulnerable to microcode-based tricks to suppress the XOR mixing, and instead substitute vulnerable data. We'd never know it's there, because microcode is closed-source and updated whenever Intel likes.

Update: see also <http://www.metzdowd.com/pipermail/cryptography/2013-December/019065.html>
A XOR B can be replicated in multiple instructions as ((NOT A) AND B) or (A and (NOT B)). This could be used to validate the result of XOR with some confidence that a targeted backdoor would be increasingly difficult to implement over multiple instructions.