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: <20180518023209.GD15263@thunk.org>
Date:   Thu, 17 May 2018 22:32:09 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Trent Piepho <tpiepho@...inj.com>
Cc:     "sultanxda@...il.com" <sultanxda@...il.com>,
        "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`

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:

commit edc1c90cb972fdca1f66be5a8e2b0706bd2a4949
Author: Karel Zak <kzak@...hat.com>
Date:   Tue Mar 20 14:17:24 2018 +0100

    lib/randutils: don't break on EAGAIN, use usleep()
    
    The current code uses lose_counter to make more attempts to read
    random numbers. It seems better to wait a moment between attempts to
    avoid busy loop (we do the same in all-io.h).
    
    The worst case is 1 second delay for all random_get_bytes() on systems
    with uninitialized entropy pool -- for example you call sfdisk (MBR Id
    or GPT UUIDs) on very first boot, etc. In this case it will use libc
    rand() as a fallback solution.
    
    Note that we do not use random numbers for security sensitive things
    like keys or so. It's used for random based UUIDs etc.
    
    Addresses: https://github.com/karelzak/util-linux/pull/603
    Signed-off-by: Karel Zak <kzak@...hat.com>

commit a9cf659e0508c1f56813a7d74c64f67bbc962538
Author: Carlo Caione <carlo@...lessm.com>
Date:   Mon Mar 19 10:31:07 2018 +0000

    lib/randutils: Do not block on getrandom()
    
    In Endless we have hit a problem when using 'sfdisk' on the really first
    boot to automatically expand the rootfs partition. On this platform
    'sfdisk' is blocking on getrandom() because not enough random bytes are
    available. This is an ARM platform without a hwrng.
    
    We fix this passing GRND_NONBLOCK to getrandom(). 'sfdisk' will use the
    best entropy it has available and fallback only as necessary.
    
    Signed-off-by: Carlo Caione <carlo@...lessm.com>

Interestingly, these commits in util-linux landed *before* the patches
to address CVE-2018-1108 appeared in the kernel in April 2019.  This
was because the issue of libuuid was blocking on a handful of embedded
systems even for we made this change in Linux's random driver.  (It
just made this problem more likely to be visbile on a larger number of
systems; but it was always there.)

					- Ted