linux-kernel - Re: Linux messages full of `random: get_random

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 linux-hardening linux-cve-announce 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:   Fri, 18 May 2018 01:27:03 +0000
From:   Trent Piepho <tpiepho@...inj.com>
To:     "sultanxda@...il.com" <sultanxda@...il.com>,
        "tytso@....EDU" <tytso@....EDU>
CC:     "jannh@...gle.com" <jannh@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Linux messages full of `random: get_random_u32 called from`

Since I wasn't on this thread from the start, I can only find a way to
reply to message in mbox format on patchwork, and this seemed the best.

On Fri, 2018-04-27 at 16:10 -0400, Theodore Tso wrote:
> 
> 
> This is why ultimately, we do need to attack this problem from both
> ends, which means teaching userspace programs to only request
> cryptographic-grade randomness when it is really needed --- and most
> of the time, if the user has not logged in yet, you probably don't
> need cryptographic-grade randomness....

I've hit this on an embedded system.  mke2fs hangs trying to format a
persistent writable filesystem, which is where the random seed to
initialize the kernel entropy pool would be stored, because it wants 16
bytes of non-cryptographic random data for a filesystem UUID, and util-
linux libuuid calls getrandom(16, 0) - no GRND_RANDOM flag - and this
hangs for over four minutes.

Some things I've seen here don't work in the embedded world.

The user will not log in.  No one logs in.  There are not even user
accounts with a valid password that could log in.

The storage comes pre-written with a static image from the manufacturer
or is programmed from a static image via JTAG or some other out of band
step.  It cannot be different from device to device when it first
boots.  No saved entropy.

The bootloader gets entropy from writable storage to give to the
kernel?  Can't do that.  The bootloader has no access to writable
storage.

I understand that if someone wants cryptographic-grade randomness early
in boot when that just isn't available and isn't going to be available,
then that isn't going to happen and lying to the consumer about the
randomness of the data isn't the answer.

But I just want UUIDs for a filesystem.  And the systemd machineid for
the journal file.  It seems the util-linux authors thought, apparently
incorrectly, that getrandom() without GRND_RANDOM was a good way to do
get it.

What is the right way?  The fact that so many userspace consumers get
it wrong might be a sign that this is lacking or at least very non-
obvious.

I want random data and I want it now.  It's ok if it's low entropy. 
This seems to be a very real, and unavoidable, thing in early boot. 
And crng_init == 1 seems to be the intended way to do this.  What's the
way to get random data of crng_init==1 quality without blocking?