LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Trent Piepho <tpiepho@impinj.com>
Cc: "sultanxda@gmail.com" <sultanxda@gmail.com>,
	"jannh@google.com" <jannh@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Linux messages full of `random: get_random_u32 called from`
Date: Thu, 17 May 2018 22:32:09 -0400	[thread overview]
Message-ID: <20180518023209.GD15263@thunk.org> (raw)
In-Reply-To: <1526606822.30073.64.camel@impinj.com>

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@redhat.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@redhat.com>

commit a9cf659e0508c1f56813a7d74c64f67bbc962538
Author: Carlo Caione <carlo@endlessm.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@endlessm.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

  reply	other threads:[~2018-05-18  2:32 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26  4:11 Sultan Alsawaf
2018-04-26  5:00 ` Theodore Y. Ts'o
2018-04-26  5:05   ` Sultan Alsawaf
2018-04-26  7:32     ` Theodore Y. Ts'o
2018-04-26 15:17       ` Sultan Alsawaf
2018-04-26 19:25         ` Theodore Y. Ts'o
2018-04-26 20:22           ` Sultan Alsawaf
2018-04-26 20:47             ` Christian Brauner
2018-04-27  0:00               ` Theodore Y. Ts'o
2018-04-27 15:38                 ` Jason A. Donenfeld
2018-04-27 19:14                   ` Theodore Y. Ts'o
2018-04-26 23:56             ` Theodore Y. Ts'o
2018-04-27  5:20               ` Sultan Alsawaf
2018-04-27 20:10                 ` Theodore Y. Ts'o
2018-04-27 22:59                   ` Sultan Alsawaf
2018-04-29 14:32                   ` Pavel Machek
2018-04-29 17:05                     ` Sultan Alsawaf
2018-04-29 18:41                       ` Pavel Machek
2018-04-29 20:20                         ` Sultan Alsawaf
2018-04-29 21:18                           ` Pavel Machek
2018-04-29 21:34                             ` Sultan Alsawaf
2018-04-29 22:05                           ` Theodore Y. Ts'o
2018-04-29 22:26                             ` Sultan Alsawaf
2018-04-29 22:43                               ` Jason A. Donenfeld
2018-04-29 22:49                                 ` Sultan Alsawaf
2018-04-30  0:11                                   ` Theodore Y. Ts'o
2018-04-30  4:34                                     ` Sultan Alsawaf
2018-04-30 16:11                                       ` Theodore Y. Ts'o
2018-05-01 19:53                                         ` Pavel Machek
2018-04-29 22:43                             ` Pavel Machek
2018-04-30  0:32                             ` Laura Abbott
2018-04-30 21:12                             ` Jeremy Cline
2018-05-01 11:52                               ` Justin Forbes
2018-05-01 12:55                                 ` Theodore Y. Ts'o
2018-05-01 22:35                                   ` Justin Forbes
2018-05-02  0:02                                     ` Theodore Y. Ts'o
2018-05-02 12:09                                       ` Justin Forbes
2018-05-02 16:26                                         ` Theodore Y. Ts'o
2018-05-02 17:49                                           ` Laura Abbott
2018-05-02 22:25                                             ` Theodore Y. Ts'o
2018-05-03  6:19                                               ` Pavel Machek
2018-05-03 12:23                                               ` Justin Forbes
2018-05-02  0:43                                     ` Sultan Alsawaf
2018-05-02  0:56                                       ` Theodore Y. Ts'o
2018-05-02  1:11                                         ` Sultan Alsawaf
2018-04-29 18:30                   ` Sultan Alsawaf
2018-04-29 20:08                     ` Theodore Y. Ts'o
2018-05-18  1:27                   ` Trent Piepho
2018-05-18  2:32                     ` Theodore Y. Ts'o [this message]
2018-05-18 22:56                       ` Trent Piepho
2018-05-18 23:22                         ` Theodore Y. Ts'o
2018-05-21 18:39                           ` Trent Piepho
2018-04-29 14:29               ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2018-04-24 11:48 Paul Menzel
2018-04-24 13:56 ` Theodore Y. Ts'o
2018-04-24 14:30   ` Paul Menzel
2018-04-24 15:49   ` Theodore Y. Ts'o
2018-04-24 15:56     ` Paul Menzel
2018-04-25  7:41       ` Theodore Y. Ts'o
2018-04-26  3:48         ` Paul Menzel
2018-04-29 14:22           ` Pavel Machek
2018-04-29 23:02   ` Dave Jones
2018-04-29 23:07     ` Dave Jones
2018-04-30  0:21       ` Theodore Y. Ts'o
2018-04-26  5:51 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180518023209.GD15263@thunk.org \
    --to=tytso@mit.edu \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sultanxda@gmail.com \
    --cc=tpiepho@impinj.com \
    --subject='Re: Linux messages full of `random: get_random_u32 called from`' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).