linux-kernel - Re: [PATCH v4 0/6] Seeding DRBG with more entropy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150503205834.GJ10014@thunk.org>
Date:	Sun, 3 May 2015 16:58:34 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	herbert@...dor.apana.org.au, Paul Bolle <pebolle@...cali.it>,
	Andreas Steffen <andreas.steffen@...ongswan.org>,
	Sandy Harris <sandyinchina@...il.com>,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org
Subject: Re: [PATCH v4 0/6] Seeding DRBG with more entropy

On Sun, May 03, 2015 at 05:33:00PM +0200, Stephan Mueller wrote:
> The patch set adds an in-kernel /dev/random equivalent that was discussed with
> Ted Ts'o last July -- see [2] and [3]. A test module for testing the
> asynchronous operation of the in-kernel /dev/random is given with the code
> below.
> 
> Ted: shall we really create and maintain a new entropy pool (the kernel_pool),
> or should the in-kernel /dev/random logic draw directly from the input_pool?
> In other words, shall we drop the first patch and update the 2nd patch to
> use input_pool? Also, I would not recommend using the blocking_pool as this
> would mix kernel and user land operation.

I'd drop the 3rd pool, and just simply block until the non-blocking
pool has been initialized.  That's now considered the best practice
for userspace programs, which is to use getrandom(2), which by default
will block until the nonblocking pool has been initialized with an
estimated 128 bits of entropy, and after that point, all of the kernel
users should be quite satisfied with cryptographic entropy.

Certainly from the perspective of the perspective of a NIST evaluator
for a DRBG, using if they're happy using jitterentropy as a noise
source, they should be quite happy using the non-blocking pool as a
noise source, so long as it has been properly initialized.

As far as the concern of user space being able to block a kernel user
"indefinitely", in practice I really don't think that's going to be an
issue as far as boot-time initialization is concerned.  In practice
the urandom pool gets 128 bits of entropy *very* quickly, as in,
before the boot process is finished.

[    1.368585] random: systemd-udevd urandom read with 21 bits of entropy available
[    2.870497] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
[    3.217209] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[    3.497191] random: nonblocking pool is initialized
[    7.705482] EXT4-fs (dm-9): mounted filesystem with ordered data mode. Opts: (null)
[    8.007435] EXT4-fs (dm-10): mounted filesystem with ordered data mode. Opts: (null)
[    8.165517] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

(And if the attacker is able to inject arbitrary programs running
during the init sequence, they are almost certainly running as root,
and you've got other problems.)

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/