4 ms·
Very disappointing to hear that Debian and some other distros enabled CONFIG_RANDOM_TRUST_CPU. I'd rather not be relying on Intel hardware to do something so i
by buildzr 7y ago
Very disappointing to hear that Debian and some other distros enabled CONFIG_RANDOM_TRUST_CPU.
I'd rather not be relying on Intel hardware to do something so important correctly.
- pmlnr 7y agoYou'd rather rely on... systemd?
- fooker 7y agoAn open source software stack vs a Frankenstein Minix running with mysterious powers over your computer, do you even have to ask?
- bwvfr 7y agoAn open source software stack programmed by Poettering.
- AlotOfReading 7y agoThe management engine doesn't have anything to do with RDRAND. What's your point here?
- kroeckx 7y agoWhy do you trust Intel less then any other hardware RNG you might have? Do you trust the one in the TPM? Or do you just not trust hardware to collect entropy?
- deleted 7y ago[deleted]
- pjc50 7y agoAnd yet you trust it to run all your other instructions? This is kind of a mad threat model. The processor can see everything, change anything, and do so at any time.
- buildzr 7y agoThat's fair I suppose, the difference being that there's a lot more ways to screw up instruction backdoors and make them extremely visible than RDRAND, where the output is claimed to be unpredictable. In the end it's a defense in depth approach - I simply think the original and default Linux kernel policy of demanding sufficient entropy from other means is preferable from a security perspective. Theodore Tso has some good posts on this on the kernel mailing lists. Due to the way these sources get mixed, it would only improve security to turn this option off.
- sneak 7y agoThe kernel does not provide the cpu’s random number generator data directly to downstream users. It is mixed into the entropy pool, same as curl’ing news.google.com into /dev/random. Don’t worry about it.