Ted, last week you proposed an rfc patch to gather entropy from the CPU's hwrng, and I was pleased - until I discovered one of my stalling desktop machines does not have a hwrng. At that point I thought that the problem was only from reading /dev/random, so I went away to look at persuading the immediate consumer (unbound) to use /dev/urandom. Did that, no change. Ran strace from the bootscript, confirmed that only /dev/urandom was being used, and that it seemed to be blocking. Thought maybe this was the olnl problematic bootscript, tried moving it to later, but hit the same problem on chronyd (again, seems to use urandom). And yes, I probably should have started chronyd first anyway, but that's irrelevant to this problem. BUT: I'm not sure if I've correctly understood what is happening. It seems to me that the fix for CVE-2018-1108 (4.17-rc1, 4.16.4) means /dev/urandom will now block until fully initialised. Is that correct and intentional ? If so, to get the affected desktop machines to boot I seem to have some choices: 1. Wait for two and a half minutes (timed on the kaveri, the haswell seemed to take a similar time). 2. Sit at the keyboard and start thumping it once userspace has started. 3. For the haswell, apply your patch and trust that the CPU has not been backdored 4. Run haveged. The latter certainly lets it boot in a reasonable time, but people who understand this seem to regard it as untrustworthy. For users of /dev/urandom that is no big deal, but does it not mean that the values from /dev/random will be similarly untrustworthy and therefore I should not use this machine for generating long-lived secure keys ? TIA. ĸen
