14 ms·
Some AMD CPU's RDRAND might not return random data after a suspend/resume
- zokier 8y agoNote that the corresponding kernel bug was reported already in 2014. https://bugzilla.kernel.org/show_bug.cgi?id=85911 https://bugzilla.kernel.org/show_bug.cgi?id=85911
- nneonneo 8y agoOh, this could be really bad. I wonder if any private keys are compromised this way - would certainly be nice to know what rdrand is returning if it isn’t random data.
- lelf 8y agoCatchy title. Nowhere it says it returns non-random data. It just fails.
- butterisgood 8y agoSure it does... read all the posts. Also read all the history. Also read this from 2013 " I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction... Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea. " And this https://www.theregister.co.uk/2013/09/10/torvalds_on_rrrand_nsa_gchq/ https://www.theregister.co.uk/2013/09/10/torvalds_on_rrrand_... So, uh, this isn't news, and isn't limited to AMD. Sure it'd be nice to fix.
- jawnv6 8y agoI fail to see how a dev talking about a wholly unrelated implementation from an entirely different vendor has anything to bear on this conversation unless you're just maliciously spreading FUD around the entire concept of random numbers. Do you actually know if the instruction is faulting or delivering back non-random data ("sure it does...")? Is the non-random data 0's or something with a pattern like 0x9090? Does that match the Intel implementation's behavior exactly?
- lelf 8y agoRDRAND is not guaranteed to always succeed (and never was). You’re supposed to retry on failure. (Although linked in that thread systemd code has fallback anyway, so I’m not sure how it fails at all). Edit: not to mention that it’s better just to not use it, ever. Quite sane and sensible thing.
- baq 8y agoi don't see any reason to not xor rdrand output with a prng if rdrand is available. please enlighten us why you think otherwise as i'm really interested in assumptions that lead to this conclusion.
- lvh 8y agoDo you mean if a PRNG is available? Because the answer is obvious if RDRAND is available: you don't do that because sometimes it fails, failure is almost always catastrophic but sublte, and CSRPNGs are not a bottleneck in almost all cases.
- amluto 8y agoRDRAND has major benefits over any CSPRNG: there is no software-visible state that could possibly leak. With attacks like Spectre, there’s always a concern that your CSPRNG secrets could be leaked.
- lvh 7y agoThe scheme we’re discussing XORs the two at the end, so that flaw doesn’t apply. Also: empirically, “kernel leaks CSPRNG” state does not seem to be as much of a problem as “userspace is convinced it knows better than urandom/getrandom”.
- zaroth 8y agoSounds like a bit of code which was hard to trigger the negative test and therefore the fallback failed to work properly. 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.
- oakwhiz 8y agohttps://news.ycombinator.com/item?id=6336505 https://news.ycombinator.com/item?id=6336505
- fpgaminer 8y agoFor the lazy, this is a link to a comment by Theodore Ts'o, kernel dev, who says: > I am so glad I resisted pressure from engineers working at Intel to let /dev/random in Linux rely blindly on the output of the RDRAND instructure. Relying solely on an implementation sealed inside a chip and which is impossible to audit is a BAD idea. Quoting from the article... Theodore Ts'o is maintainer of the ext filesystems (particularly ext4), as well as, IIRC, /dev/random and other CSRNG related components of the kernel. Thank you, Theodore Ts'o.
- agwa 7y agoTheodore Ts'o is responsible for perpetuating the myth that entropy/randomness can run out, leading systemd (and other software) to do crazy things, such as trying to use RDRAND, to avoid "drain[ing] randomness from the kernel pool". The bugs and security vulnerabilities resulting from this myth probably neutralize the benefit that came from from his resistance to RDRAND in the kernel.
- BeefySwain 7y ago> the myth that entropy/randomness can run out Can you expand on this, or link to some sources that expand on this idea that the assumption above is wrong? As a person who has not dealt with crypto really at all I had heard this explained several times before and assumed it was generally accepted.
- deleted 7y ago[deleted]
- colmmacc 7y ago128-bits of random data is sufficient to securely generate a stream of 100s of terabytes of random data. It's not /that/ hard to find 128-bits of true entropy, even during boot phase. Here's one example: 1. Seed with any fixed hardware IDs 2. Mix-in the wall clock time 3. Spin up a kernel thread and flip a bit on/off in a tight loop. Interrupt it every 100 nanoseconds and take the value of the bit at that time. Do this 256 times. Mix that in too. 4. Mix-in 256-bits from RDRAND 5. Mix-in timings from other interrupts as and when they happen. 6. Repeat steps 4. and 5. ad infinitum. By step 4 we have taken 26 microseconds and we have the kind of entropy I would be comfortable generating an RSA private key with. Note that step 3 is effectively a measure of how precise the system clock and CPU are. Attacks have been demonstrated against step 3, but they require co-resident processes and don't apply during the boot-phase, if you've got a dedicated core at least. In theory if system clocks and CPU got super precise it could become too deterministic, but the point is the likelihood of /both/ that happening /and/ RDRAND being broken.
- throwayEngineer 8y agoWow, so when would be the worst time to suspend your computer? The only time I imagine this, is when generating a private key for a production environment.
- deleted 8y ago[deleted]
- hedora 8y agoMy reading is that systemd uses the cryptographically secure rng to generate a unique id for a filename, and doesn't handle collisions properly. sigh
- floatboth 8y agoWell, not handling collisions helps a lot with exposing bad CSPRNGs. If they (and e.g. OpenSSH as mentioned in the original 2014 bug report) did handle collisions, it could've remained unnoticed.
- rwmj 7y agoThere shouldn't be collisions. I mean that really: if you see a collision it's so much more likely that your computer / program / source of randomness is faulty [as in this case] than that the two random numbers collided that it's not worth considering the collision case.
- lokedhs 7y agoBut there can be collisions, at least in theory. And as we can see, in practice too. Not checking for collisions because you trust that an RNG returns unique values is a fallacy and should be avoided. Especially since it's so easy to deal with the problem.
- codedokode 7y agoIt would be better to report the collision because most likely it means some error.
- lvh 8y agoIs there a good reason this doesn't just use urandom/getrandom? This doesn't look like it's in the "we're so early in boot I haven't restored the random seed yet" case, for example.
- jsnell 8y agoNo. There's a bad reason though. Want to guess what? https://github.com/systemd/systemd/blob/master/src/basic/random-util.c#L83 https://github.com/systemd/systemd/blob/master/src/basic/ran... Yes, the old "draining entropy" fallacy.
- dzdt 8y agoWhy do you say draining entropy is a fallacy? It is certainly true that entropy recorded from I/O sources accumulates at a very limited rate.
- deleted 8y ago[deleted]
- i80and 8y agoThere's no way to "use up" your entropy; this is a persistent myth that's been hanging around the Linux world for a very long time. * https://www.2uo.de/myths-about-urandom/#what-about-entropy-running-low https://www.2uo.de/myths-about-urandom/#what-about-entropy-r... * https://www.mail-archive.com/cryptography@randombit.net/msg04763.html https://www.mail-archive.com/cryptography@randombit.net/msg0...
- deleted 8y ago[deleted]
- wolf550e 8y agoBecause after you gather ~256 bits of entropy from I/O sources (or rdrand^H^H^H rdseed [1]), using it to generate infinite output of /dev/urandom does not drain it. Adding more entropy only helps if the entropy pool inner state leaked, it is not needed to add more entropy because it drained through using it. Proof: 1. Take 256 bits of entropy. 2. Use HKDF to generate 128 bit key and 64 bit nonce. 3. Use key and nonce for AES-CTR with all possible 2^64 counter values to produce 2^68 bytes of output. 4. goto 2. If you can compute the inner state of the RNG (and thus predict future output) by just observing the output (not through side channels), using any amount of output, then all modern symmetric crypto is broken. If you can't, then using the entropy in an RNG does not drain the entropy pool. And here is a CCC talk about it: https://www.youtube.com/watch?v=OSfmtRc4VsE https://www.youtube.com/watch?v=OSfmtRc4VsE 1 - https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed https://software.intel.com/en-us/blogs/2012/11/17/the-differ... EDIT: Thanks for 'dragontamer for pointing out difference between rdrand and rdseed.
- ricardobeat 8y agoLater in the thread: > Given that RDRAND is allowed to fail, it seems to me that you should either try it only once, or only a few times, before falling back to whatever code is used when RDRAND is not implemented.
- JdeBP 8y ago... which is what the systemd code actually does. The problem is that there appears to be a possible AMD processor state, caused by suspend+resume, where the instruction succeeds but the data returned are not in fact random.
- loeg 7y agoThe other problem is that systemd's fallback is a non-random PRNG.
- JdeBP 7y agoOnly if a RANDOM_EXTEND_WITH_PSEUDO flag is set. But in fact, that flag is nowhere set in systemd outwith unit testing code. So it is not in fact another problem. Even if it were used, the calls to rand() would only happen if RDRAND first succeeded and then failed. If RDRAND always failed, systemd's true fallback is actually to getrandom() and thence to /dev/urandom. However, AMD claims in its doco that there is a FIFO of generated data provided for satisfying bursts of multiple RDRAND instructions, so it is supposedly unlikely to succeed and then fail, especially for the amounts of random data in the case at hand. AMD does not say, though, whether the FIFO is big enough to complete a 128-bit GUID, and this does after all involve a processor that can enter a mode where RDRAND succeeds and gives a constant result. It's not wholly beyond the bounds of possibility that AMD made the FIFO too small as well.
- ricardobeat 7y agoThere is no mention anywhere, in this thread nor the one from 2014, of it returning non-random data from the issue reporters, just assumptions from onlookers.
- fpgaminer 8y agoAnd this is why cryptography has increasingly reduced its reliance on randomness. Strong CSPRNG that only need a single seed to be secure, signing constructions that use deterministic hashes, deterministic derived keys, DAE-secure ciphers that fail-safe when IVs are re-used, etc. Randomness is definitely something we took for granted for too long.
- Proven 7y agoBut it's cheaper!
- iamnothere 7y agoSuspend/resume seems to be the cause of a whole host of bugs; I run into obnoxious suspend problems frequently on all platforms except maybe Windows. It's so common that I've pretty much stopped using suspend on most of my machines. It's a bit inconvenient to power down / power up things each day, but I'd rather deal with that than have intermittent wifi issues, display problems, etc.
- jdironman 7y agoI consulted once for a hospital that was experience seemingly random network outages. After a few questions with the staff there it seemed to happen whenever a person stepped away from their windows (Lenovo) workstations for too long. Say, after lunch or breaks. After a wireshark of the network I determined it was a network card driver that was causing a broadcast flood on the network from multiple points for stations with the same driver version. While not the fault of Windows (I dont think anyways, as an update of the driver fixed the issue) your comment did remind me of this experience.
- iamnothere 7y agoBet the vendor made sure the drivers "worked" for suspend/resume, but only from the user point of view. I may have just been lucky with Windows on my particular hardware. A quick search turns up a bunch of different problems. I think suspend/resume may just be a particularly difficult thing to get right.