On Wed, Jun 27, 2018 at 1:11 AM, Louis Collard <louiscollard@xxxxxxxxxxxx> wrote: > > On some systems we have seen large delays in boot time, due to > blocking on a call to getrandom() before the entropy pool has been > initialized. On these systems the usual sources of entropy are not > sufficient to initialize the pool in any kind of reasonable time - > delays of minutes have been observed; the most common workaround is to > mash the keyboard for a bit ;) > > Setting a non-zero quality score causes the hwrng to be used as a > source of entropy for the pool, the pool is therefore initialized > early during boot, and no delay is observed. > We have the same issue on our embedded devices and thus carry patches in our tree that set the quality. This would be a welcome change. As a point of clarification (and correct me if I'm wrong), the TPM is always ready used to seed the rng. It just doesn't update the entropy pool estimate. So, perhaps the default value for the TPM hwrng quality should be non-zero (in addition to the module param that lets users override it)? As it stands, it encourages programmers to not use methods like getrandom() or not check the entropy pool estimate before reading from dev/urandom. They know the rng was supposedly seeded by the TPM --- the entropy estimate just wasn't updated --- so the easiest "fix" is to just not check the entropy pool estimate. I think the default config on a machine with a TPM should be that the rng is seeded by the TPM and that the entropy pool estimate is updated to reflect that. Then programs that are written properly (i.e., use getrandom()) will work correctly with no further effort from the user. Best, David
