linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv2] random: Make /dev/random wait for crng_ready
Date: Sat, 16 Feb 2019 13:23:55 -0500	[thread overview]
Message-ID: <20190216182355.GE23000@mit.edu> (raw)
In-Reply-To: <VI1PR0702MB3840E7DCBEA62BB204CA863DE4600@VI1PR0702MB3840.eurprd07.prod.outlook.com>

On Fri, Feb 15, 2019 at 01:58:20PM +0000, Bernd Edlinger wrote:
> Reading from /dev/random may return data while the getrandom
> syscall is still blocking.
> 
> Those bytes are not yet cryptographically secure.
> 
> The first byte from /dev/random can have as little
> as 8 bits entropy estimation.  Once a read blocks, it will
> block until /proc/sys/kernel/random/read_wakeup_threshold
> bits are available, which is usually 64 bits, but can be
> configured as low as 8 bits.  A select will wake up when
> at least read_wakeup_threshold bits are available.
> Also when constantly reading bytes out of /dev/random
> it will prevent the crng init done event forever.
> 
> Fixed by making read and select on /dev/random wait until
> the crng is fully initialized.
> 
> Signed-off-by: Bernd Edlinger <bernd.edlinger@hotmail.de>

This really isn't a correct way to fix things; since the blocking_pool
used for /dev/random and the CRNG state are different things, and are
fed by different sources of entropy.

What we should do is to have a separate flag which indicates that the
blocking_pool has been adequately initialized, and set it only when
the entropy count in the blocking pool is at least 128 bits.  When get
woken up by the reader lock, we would transfer entropy from the input
pool to the blocking pool, and if the pool is not yet initializedm,
and the entropy count is less than 128 bits, we wait until it is.

    		      	      	       - Ted

  reply	other threads:[~2019-02-16 18:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15  1:47 [PATCH] random: Make /dev/random wait for crng_ready Bernd Edlinger
2019-02-15  5:40 ` Bernd Edlinger
2019-02-15 13:58 ` [PATCHv2] " Bernd Edlinger
2019-02-16 18:23   ` Theodore Y. Ts'o [this message]
2019-02-16 20:12     ` Bernd Edlinger
2019-02-17  8:44     ` [PATCHv3] " Bernd Edlinger
2019-02-17 13:48       ` Bernd Edlinger
2019-02-17 20:55         ` [PATCHv4] random: Make /dev/random wait for input_pool initialized Bernd Edlinger
2019-02-19  7:16           ` Bernd Edlinger
2019-02-19 17:09             ` [PATCHv5] " Bernd Edlinger
2019-02-21  0:32               ` [PATCHv5] random: Make /dev/random wait for input_pool initializedy Theodore Y. Ts'o
2019-02-21 19:24                 ` Bernd Edlinger
2019-02-21 23:18                   ` Theodore Y. Ts'o
2019-02-22 13:45                     ` Bernd Edlinger

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=20190216182355.GE23000@mit.edu \
    --to=tytso@mit.edu \
    --cc=arnd@arndb.de \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.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).