On Thu, Feb 24, 2022 at 01:54:54AM +0100, Jason A. Donenfeld wrote: > On 2/24/22, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > I think we should be removing cases where the base_crng key is changed > > directly > > besides extraction from the input_pool, not adding new ones. Why not > > implement > > this as add_device_randomness() followed by crng_reseed(force=true), where > > the > > 'force' argument forces a reseed to occur even if the entropy_count is too > > low? > > Because that induces a "premature next" condition which can let that > entropy, potentially newly acquired by a storm of IRQs at power-on, be > bruteforced by unprivileged userspace. I actually had it exactly the > way you describe at first, but decided that this here is the lesser of > evils and doesn't really complicate things the way an intentional > premature next would. The only thing we care about here is branching > the crng stream, and so this does explicitly that, without having to > interfere with how we collect entropy. Of course we *also* add it as > non-credited "device randomness" so that it's part of the next > reseeding, whenever that might occur. Can you make sure to properly explain this in the code? - Eric
