On Fri, Sep 20, 2019 at 12:22 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > Here are some possible approaches that come to mind: > > int count; > while (crng isn't inited) { > msleep(1); > } > > and modify add_timer_randomness() to at least credit a tiny bit to > crng_init_cnt. I'd love that, but we don't actually call add_timer_randomness() for timers. Yeah, the name is misleading. What the "timer" in add_timer_randomness() means is that we look at the timing between calls. And we may actually have (long ago) called it for timer interrupts. But we don't any more. The only actual users of add_timer_randomness() is add_input_randomness() and add_disk_randomness(). And it turns out that even disk IO doesn't really call add_disk_randomness(), so the only _real_ user is that keyboard input thing. Which means that unless you sit at the machine and type things in, add_timer_randomness() _never_ gets called. No, the real source of entropy right now is add_interrupt_randomness(), which is called for all device interrupts. But note the "device interrupts" part. Not the timer interrupt. That's special, and has its own low-level architecture rules. So only the normal IO interrupts (like disk/network/etc). So timers right now do not add _anything_ to the randomness pool. Not noise, not entropy. But yes, what you can do is a jitter entropy thing, which basically does what you suggest, except instead of "msleep(1)" it does something like while (crng isn't inited) { sched_yield(); do_a_round_of_memory_accesses_etc(); add_cycle_counter_entropy(); } and with a lot of handwaving you'll convince a certain amount of people that yes, the timing of the above is unpredictable enough that the entropy you add is real. Linus