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]

Message-ID: <1526684178.31570.26.camel@impinj.com>
Date:   Fri, 18 May 2018 22:56:18 +0000
From:   Trent Piepho <tpiepho@...inj.com>
To:     "tytso@....edu" <tytso@....edu>
CC:     "jannh@...gle.com" <jannh@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "sultanxda@...il.com" <sultanxda@...il.com>
Subject: Re: Linux messages full of `random: get_random_u32 called from`

On Thu, 2018-05-17 at 22:32 -0400, Theodore Y. Ts'o wrote:
> On Fri, May 18, 2018 at 01:27:03AM +0000, Trent Piepho wrote:
> > 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.
> 
> This is fixed in util-linux 2.32.  It ships with the following commits:

I feel like "fix" might overstate the result a bit.

This ends up taking a full second to make each UUID.  Having gone to
great effort to make an iMX25 complete userspace startup in 250 ms, a
full second, per UUID, in early startup is pretty appalling.

Let's look at what we're doing after this fix:
Want non-cryptographic random data for UUID, ask kernel for it.
Kernel has non-cryptographic random data, won't give it to us.
Wait one second for cryptographic random data, which we didn't need.
Give up and create our own random data, which is non-cryptographic and
even worse than what the kernel could have given us from the start.

util-linux falls back to rand() seeded with the pid, uid, tv_sec, and
tv_usec from gettimeofday().  Pretty bad on an embedded system with no
RTC and worse than what the kernel in crng_init 1 state can give us.

What took microseconds now takes a seconds.  We have lower quality
random data than we had before.

Seems like two steps backward.  Can't we do better?

How about adding a flag to getrandom() that allows the kernel to return
low-quality data if high-quality data would require blocking?

It would seem to be a fact that there will be users of non-
cryptographic random data in early boot.  What is the best practice for
that?  To fall back to each user trying "to find randomly-looking
things on an 1990s Unix."  That doesn't seem good to me.  But what's
the better way?