4 ms·
Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it
by magicalist 13y ago
Was that really a seriously considered plan? I don't see how that would ever be a suitable /dev/random replacement. Obviously it works for /dev/urandom, but it should be added to the entropy pool for /dev/random at most.
- lambda 13y agoMatt Mackall, the former maintainer of /dev/random, actually stepped down over this issue, because Linus overrode Matt and applied Intel's patch that used their hardware random number generator directly: http://comments.gmane.org/gmane.comp.security.cryptography.randombit/4689 http://comments.gmane.org/gmane.comp.security.cryptography.r... > It's worth noting that the maintainer of record (me) for the Linux RNG quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. > From a quick skim of current sources, much of that has recently been rolled back (/dev/random, notably) but kernel-internal entropy users like sequence numbers and address-space randomization appear to still be exposed to raw RdRand output. Ted Ts'o later reverted this, separating out Intel's hardware random number generation into a separate function that could be used to seed the entropy pool but wouldn't be trusted directly as the main kernel source of random numbers: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
- Zoepfli 13y agoSounds like Linus has some explaining to do...
- gaius 13y agoIndeed. Where's Mr Sweary now, eh?
- tytso 13y agoIf Matt protested, he did so quietly/privately. I wasn't aware of the fact that he had stepped down until the authors of the paper described in http://factorable.net http://factorable.net showed up and pointed out we had a really bad problem for embedded devices on the internet. I had always assumed he had gotten too busy and distracted on other interests, since I do follow LKML, and I didn't see any kind of public debate/controversy about the change to the random driver described above. If I had to guess what happened, some intel people pushed this as a feature, probably pushing it via one of the x86 git trees, and Linus either (a) didn't notice, or (b) didn't understand the implications, and then Matt quit in a huff --- by just stopping to do work, and not even updating the entry in the MAINTAINERS file. (That didn't happen until I took over the random driver again.)
- lambda 13y agoYou're right, if he did so, it must have been in private; I searched for a while to find a message on a public mailing list about it, and could not, so resorted to linking to that later message. Regardless, I'm glad that paranoia did eventually prevail, despite Linus's original strong objections.
- lambda 13y agoAh, here's the thread I was looking for: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=1173517 http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... It doesn't really look like he had NAKed it on paranoia grounds, but more on design grounds; others brought up the paranoia arguments. You were even involved in that thread, so you should have seen his stepping down, although he didn't submit a patch to MAINTAINERS.
- tytso 13y agoNot only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool: https://lkml.org/lkml/2013/9/5/212 https://lkml.org/lkml/2013/9/5/212
- Create 13y ago"It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure." --- "The NSA's codeword for its decryption program, Bullrun, is taken from a major battle of the American civil war. Its British counterpart, Edgehill" "N.S.A. spends more than $250 million a year on its Sigint Enabling Project, which “actively engages the U.S. and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs” to make them “exploitable.”" -- http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryp... -- Bull Mountain, is Intel's code name for both the RdRand instruction and the underlying random number generator (RNG) hardware implementation. -- bull [mountain|hill] [intel|processor] http://www.googlewhack.com/ http://www.googlewhack.com/ https://xkcd.com/936/ https://xkcd.com/936/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-in-that-password/ http://subrabbit.wordpress.com/2011/08/26/how-much-entropy-i...
- rauar 13y agokudos. did Linus ever comment on the roll-back ?