On Wed, Jul 4, 2018 at 2:54 AM, Louis Collard <louiscollard@xxxxxxxxxxxx> wrote: > On Fri, Jun 29, 2018 at 9:03 PM, David R. Bild <david.bild@xxxxxxxxxx> wrote: >> 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. > > Good point. > >> >> 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)? > > That makes sense to me, however I can imagine that some users would > prefer to not have the TPM enabled as an ongoing source of entropy by > default. Fair enough. > Following on from your previous point - perhaps we can just make a > small change to how the initial seeding is done: maybe we can replace > the call to crng_slow_load (via add_early_randomness and > add_device_randomness) with a call (indirectly) to crng_fast_load. (We > might also need to increase the amount of data read at this point.) > > This would update crng_init_cnt and crng_init, and calls to getrandom > [without GRND_RANDOM] would not block. Interesting. add_hwgenereator_randomness() will call crng_fast_load(), regardless of entropy estimate/quality, if crng_init is 0. So initializing crng_init from the hwrng, regardless of quality, is already the intent. But hw_random only calls add_hwgenerator_randomness() if current_quality > 0, via the hwrng_fillfn() kthread. All that to say, I agree. add_early_randomness() should (indirectly) call crng_fast_load(), like add_hwgenerator_randomness() does. > This obviously doesn't solve the issue if there are blocking calls on > boot that are querying random rather than urandom; I don't believe > that would be a problem for our use case though. > It wouldn't be a problem for our use case either. Best, David
