LKML Archive on
 help / color / Atom feed
From: Andy Lutomirski <>
To: Pavel Machek <>
Cc: Andy Lutomirski <>,
	Theodore Tso <>,
	LKML <>,
	Linux API <>,
	Kees Cook <>,
	"Jason A. Donenfeld" <>
Subject: Re: [PATCH 0/7] Rework random blocking
Date: Mon, 9 Sep 2019 15:57:46 -0700
Message-ID: <> (raw)
In-Reply-To: <20190909094230.GB27626@amd>

On Mon, Sep 9, 2019 at 2:42 AM Pavel Machek <> wrote:
> On Thu 2019-08-29 18:11:35, Andy Lutomirski wrote:
> > This makes two major semantic changes to Linux's random APIs:
> >
> > It adds getentropy(..., GRND_INSECURE).  This causes getentropy to
> > always return *something*.  There is no guarantee whatsoever that
> > the result will be cryptographically random or even unique, but the
> > kernel will give the best quality random output it can.  The name is
> > a big hint: the resulting output is INSECURE.
> >
> > The purpose of this is to allow programs that genuinely want
> > best-effort entropy to get it without resorting to /dev/urandom.
> > Plenty of programs do this because they need to do *something*
> > during boot and they can't afford to wait.  Calling it "INSECURE" is
> > probably the best we can do to discourage using this API for things
> > that need security.
> >
> > This series also removes the blocking pool and makes /dev/random
> > work just like getentropy(..., 0) and makes GRND_RANDOM a no-op.  I
> > believe that Linux's blocking pool has outlived its usefulness.
> > Linux's CRNG generates output that is good enough to use even for
> > key generation.  The blocking pool is not stronger in any material
> > way, and keeping it around requires a lot of infrastructure of
> > dubious value.
> Could you give some more justification? If crng is good enough for
> you, you can use /dev/urandom...

Take a look at the diffstat.  The random code is extremely security
sensitive, and it's made considerably more complicated by the need to
support the blocking semantics for /dev/random.  My primary argument
is that there is no real reason for the kernel to continue to support

> are
> > This series should not break any existing programs.  /dev/urandom is
> > unchanged.  /dev/random will still block just after booting, but it
> > will block less than it used to.  getentropy() with existing flags
> > will return output that is, for practical purposes, just as strong
> > as before.
> So what is the exact semantic of /dev/random after your change?

Reads return immediately if the CRNG is initialized, i.e reads return
immediately if and only if getentropy(..., 0) would succeed.
Otherwise reads block.


      reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-30  1:11 Andy Lutomirski
2019-08-30  1:11 ` [PATCH 1/7] random: Don't wake crng_init_wait when crng_init == 1 Andy Lutomirski
2019-08-30  1:11 ` [PATCH 2/7] random: Add GRND_INSECURE to return best-effort non-cryptographic bytes Andy Lutomirski
2019-08-30  1:11 ` [PATCH 3/7] random: Ignore GRND_RANDOM in getentropy(2) Andy Lutomirski
2019-08-30  1:11 ` [PATCH 4/7] random: Make /dev/random be almost like /dev/urandom Andy Lutomirski
2019-08-30  1:11 ` [PATCH 5/7] random: Remove the blocking pool Andy Lutomirski
2019-08-30  1:11 ` [PATCH 6/7] random: Delete code to pull data into pools Andy Lutomirski
2019-08-30  1:11 ` [PATCH 7/7] random: Remove kernel.random.read_wakeup_threshold Andy Lutomirski
2019-08-30  1:49 ` [PATCH 0/7] Rework random blocking Theodore Y. Ts'o
2019-08-30  2:01   ` Andy Lutomirski
2019-09-09  9:42 ` Pavel Machek
2019-09-09 22:57   ` Andy Lutomirski [this message]

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \

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

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone