lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 11 Sep 2019 18:00:19 +0100
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     "Ahmed S. Darwish" <darwish.07@...il.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

On Wed, Sep 11, 2019 at 5:45 PM Linus Torvalds
<torvalds@...ux-foundation.org> 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

Powered by blists - more mailing lists