LKML Archive on
 help / color / Atom feed
From: Andy Lutomirski <>
To: "Theodore Y. Ts'o" <>
Cc: Andy Lutomirski <>,
	Theodore Tso <>,
	LKML <>,
	Linux API <>,
	Kees Cook <>,
	"Jason A. Donenfeld" <>
Subject: Re: [PATCH 0/7] Rework random blocking
Date: Thu, 29 Aug 2019 19:01:49 -0700
Message-ID: <> (raw)
In-Reply-To: <>

> On Aug 29, 2019, at 6:49 PM, Theodore Y. Ts'o <> wrote:
>> On Thu, Aug 29, 2019 at 06:11:35PM -0700, Andy Lutomirski wrote:
>> 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.
> It's too late for the 5.4 cycle for a change of this magnitude, and
> I'd just as soon let this wait until *after* the LTS kernel gets cut.
> The reason for this is because at the moment, there are some PCI
> compliance labs who believe that the "true randomness" of /dev/random
> is necessary for PCI compliance and so they mandate the use of
> /dev/random over /dev/urandom's "cryptographic randomness" for that
> reason.  A lot of things which are thought to be needed for PCI
> compliance that are about as useful as eye of newt and toe of frog,
> but nothing says that PCI compliance (and enterprise customer
> requirements :-) have to make sense.
> It may be that what we might need to really support people (or stupid
> compliance labs) who have a fetish for "true randomness" to get a
> better interface for hardware random number generators than
> /dev/hwrng.  Specifically, one which allows for a more sane way of
> selecting which hardware random number generator to use if there are
> multiple available, and also one where we mix in some CRNG as a
> whitening step just case the hardware number generator is busted in
> some way.  (And to fix the issue that at the moment, if someone evil
> fakes up a USB device with the USB manufacturer and minor device
> number for a ChosKey device that generates a insecure sequence, it
> will still get blindly trusted by the kernel without any kind of
> authentication of said hardware device.)
> That probably means we need to come up with a new interface than
> /dev/hwrng, or have some way of configuring /dev/random to use a
> hardware RNG device for those people who really care about "true
> randomness".  The current /dev/hwrng interface and how it is
> configured via sysfs is pretty baroque IMO.

Hmm. Does this really need to be in the kernel?  ISTM it should be straightforward to write a little CUSE program that grabs bytes from RDSEED or RDRAND, TPM, ChaosKey (if enabled, with a usb slot selected!), and whatever other sources are requested and, configurable to satisfy whoever actually cares, mixes some or all with a FIPS-compliant, provably-indististinguishable-from-random, definitely not Dual-EC mixer, and spits out the result.  And filters it and checks all the sources for credibility, and generally does whatever the user actually needs.

And the really over-the-top auditors can symlink it to /dev/random.

Do the PCI folks actually care that it’s in the kernel?

As an aside, the first two patches could plausibly land before the rest of the series if that seems appropriate.

  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 [this message]
2019-09-09  9:42 ` Pavel Machek
2019-09-09 22:57   ` Andy Lutomirski

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

* 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