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: "jannh@google.com" <jannh@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"sultanxda@gmail.com" <sultanxda@gmail.com>
Subject: Re: Linux messages full of `random: get_random_u32 called from`
Date: Fri, 18 May 2018 19:22:56 -0400	[thread overview]
Message-ID: <20180518232256.GA23628@thunk.org> (raw)
In-Reply-To: <1526684178.31570.26.camel@impinj.com>

On Fri, May 18, 2018 at 10:56:18PM +0000, Trent Piepho wrote:
> 
> 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.

So what util-linux's libuuid could do is fall back to using
/dev/urandom instead.  Whether or not you retry for a second before
you fall back to /dev/urandom really depends on how important the
second U in UUID ("unique") is to you.  If you use lower quality
randomness, you can potentially risk getting non-unique UUID's.

If you don't worry leaking your computer's identity and the time when
the UUID was generated, the application could also use the time-based
UUID's.  There are privacy implications for doing so, it's not
something we can do automatically (or at least I can't recommend it).
Also, if you don't have the clock sequence file and/or you don't have
a writable root, you might need some randomness anyway to protect
against non-monotonically increasing system time.

> 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?

We could add a new flag to getrandom(2), but application authors can
just as easily fall back to using /dev/urandom.  The real concern I
have is application authors that actually *really* need cryptographic
randomness, but they're too lazy to figure out a way to defer key
generation until the last possible moment.

There are other things we can do to add support in the bootloader to
read an entropy state file and inject it into the kernel alongside the
initrd and boot command line.  But that doesn't completely solve the
problem; you still have to deal with the "frest from the factory,
first time out of box" experience.  And if you have trusted random
number generation hardware, and are reasonably certain you don't have
to worry about a state-sponsored agency from intercepting hardware
shipments and gimmicking your hardware, that can be a solution as
well.

So there are things we can do to improve some of the scenarios.
Unfortunately, there is no silver bullet that will address all of
them.

					- Ted

  reply	other threads:[~2018-05-18 23:23 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
2018-05-18 22:56                       ` Trent Piepho
2018-05-18 23:22                         ` Theodore Y. Ts'o [this message]
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=20180518232256.GA23628@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).