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.
