linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Stephan Mueller <smueller@chronox.de>
Cc: linux-crypto@vger.kernel.org,
	Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
	stable@kernel.org
Subject: Re: [PATCH 1/5] random: fix crng_ready() test
Date: Fri, 13 Apr 2018 08:53:13 -0400	[thread overview]
Message-ID: <20180413125313.GA2633@thunk.org> (raw)
In-Reply-To: <1699469.KmO53oa8XU@tauon.chronox.de>

On Fri, Apr 13, 2018 at 07:38:30AM +0200, Stephan Mueller wrote:
> > The crng_init variable has three states:
> > 
> > 0: The CRNG is not initialized at all
> > 1: The CRNG has a small amount of entropy, hopefully good enough for
> >    early-boot, non-cryptographical use cases
> > 2: The CRNG is fully initialized and we are sure it is safe for
> >    cryptographic use cases.
> > 
> > The crng_ready() function should only return true once we are in the
> > last state.
> > 
> Do I see that correctly that getrandom(2) will now unblock after the 
> input_pool has obtained 128 bits of entropy? Similarly for 
> get_random_bytes_wait.

Correct.

> As this seems to be the only real use case for crng_ready (apart from 
> logging), what is the purpose of crng_init == 1?

Immediately after boot (crng_init state 0), we funnel the harvested
entropy from add_interrupt_entropy() directly to the CRNG pool.  The
goal is to get at least some amount of entropy into the CRNG is it's
not blatently predictable.  When we have accomplished this, by mixing
in 2 * CHACHA20_KEY_SIZE bytes of input from add_input_randomness, we
enter state crng_init state 1.

In crng_init state 1, we start funnelling the harvested entropy to the
input_pool.  Once we have accumulated 128 bits of entropy in the input
pool, we then reseed the CRNG from the input_pool, and we consider the
CRNG to be fully intialized.

During crng_init state 1, the CRNG is basically in a "good enough for
government work" state.  It's going to get used by things like initial
TCP sequence numbers, and UUID's by udev, et. al, but I wouldn't want
to use it for anything that has strong cryptographic use cases.

It would be preferable if nothing in the kernel and early systemd
startup used get_random_bytes() or /dev/urandom or getrandom(2) w/
GRND_NONBLOCK.  Unfortunately, (a) there is a lot of legacy code which
still uses /dev/urandom and not getrandom(2) and (b) in some cases,
such as initialization of the Stack Canary, the kernel simply can't
wait for the CRNG to be fully initialized.  Or if the kernel needs
enough of the networking stack to mount an NFS root file system, for
example.

This was always the original design intent, but I screwed up and no
one noticed until Jann reached out to be and said, "Hey.... this
doesn't seem to make much sense".

Regards,

					- Ted

  reply	other threads:[~2018-04-13 12:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13  1:30 [PATCH 1/5] random: fix crng_ready() test Theodore Ts'o
2018-04-13  1:30 ` [PATCH 2/5] random: use a different mixing algorithm for add_device_randomness() Theodore Ts'o
2018-04-13  1:30 ` [PATCH 3/5] random: set up the NUMA crng instances after the CRNG is fully initialized Theodore Ts'o
2018-04-13 22:31   ` kbuild test robot
2018-04-13  1:30 ` [PATCH 4/5] random: crng_reseed() should lock the crng instance that it is modifying Theodore Ts'o
2018-04-13  1:30 ` [PATCH 5/5] random: add new ioctl RNDRESEEDCRNG Theodore Ts'o
2018-04-13  5:38 ` [PATCH 1/5] random: fix crng_ready() test Stephan Mueller
2018-04-13 12:53   ` Theodore Y. Ts'o [this message]
2018-04-13 13:05     ` Stephan Mueller
2018-04-13 17:00       ` Theodore Y. Ts'o
2018-05-17  0:07         ` Srivatsa S. Bhat
2018-05-17 20:53           ` Theodore Y. Ts'o
2018-05-17  6:01         ` Christophe LEROY
2018-05-17 20:56           ` Theodore Y. Ts'o
2018-05-02 16:18 ` Geert Uytterhoeven

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=20180413125313.GA2633@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=smueller@chronox.de \
    --cc=stable@kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).