On Wed, Sep 11, 2019 at 5:45 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> So I'd be inclined to either lower the limit regardless - and perhaps
> make the "user space asked for randomness much too early" be a big
> *warning* instead of being a basically fatal hung machine?
Hmm. Just testing - normally I run my laptop with TRUST_CPU enabled,
so I never see this any more, but warning (rather than waiting) is
what we still do for the kernel.
And I see
[ 0.231255] random: get_random_bytes called from
start_kernel+0x323/0x4f5 with crng_init=0
and that's this code:
add_latent_entropy();
add_device_randomness(command_line, strlen(command_line));
boot_init_stack_canary();
in particular, it's the boot_init_stack_canary() thing that asks for a
random number for the canary.
I don't actually see the 'crng init done' until much much later:
[ 21.741125] random: crng init done
but part of that may be that my early boot is slow due to having an
encrypted disk and so the bootup ends up waiting for me to type the
passphrase.
But this does show that
(a) we have the same issue in the kernel, and we don't block there
(b) initializing the crng really can be a timing problem
The interrupt thing is only going to get worse as disks turn into
ssd's and some of them end up using polling rather than interrupts..
So we're likely to see _fewer_ interrupts in the future, not more.
Linus
