after distributing patches for the Linux-RNG - a new approach for the last
half year, I would like to submit this RFC for inclusion into the kernel.

The following patch set provides a different approach to /dev/random which
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the legacy /dev/random is to provide
sufficient entropy during boot time as well as in virtual environments and when
using SSDs. A secondary design goal is to limit the impact of the entropy
collection on massive parallel systems and also allow the use accelerated
cryptographic primitives. Also, all steps of the entropic data processing are

The design and implementation is driven by a set of goals described in [1]
that the LRNG completely implements. Furthermore, [1] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and

Booting the patch with the kernel command line option
"dyndbg=file drivers/char/lrng* +p" generates logs indicating the operation
of the LRNG. Each log is pre-pended with "lrng:".

The LRNG has a flexible design by allowing an easy replacement of the
deterministic random number generator component. For the request of inclusion
into the kernel, the scope of the LRNG is limited compared to the previous
patch sets. The following components are not part of the patch set and are
intended for a separate submission:

- FIPS 140-2 continuous random number generator test -- the LRNG is therefore
  not compliant with FIPS 140-2 requirements.

- Support for using the SP800-90A DRBG.

[1] http://www.chronox.de/lrng.html

Changes (compared to v11 of the previous patch set):

* use PTR_ERR_OR_ZERO as suggested by Julia Lawall

* fixed coccocinelle warnings

* fixed cppcheck style hints

* streamlined add_interrupt_randomness

* all DRNG-specific code is re-allocated to the C files specific to the
  respective DRNG

* rename all macros from DRBG -> DRNG

* rename all functions from *drbg* -> *drng*

* functions grouped into pdrng and sdrng processing for easier reading

* Use Jitter RNG to seed even the init RNG for entropy at earliest boot time
  which implies that the very first random number generated by the LRNG is
  seeded with the Jitter RNG:
[    0.029839] lrng: Jitter RNG working on current system
[    0.030000] lrng: obtained 32 bits of entropy from Jitter RNG noise source

* incorporate wait_for_random_bytes from Jason A. Donenfeld

* incorporate invalidate_batched_entropy from Jason A. Donenfeld

* incorporate debug logs for unseeded DRNGs from Jason A. Donenfeld including
  rate limiting from Ted Ts'o

* rename lrng_standalone.c -> lrng_chacha20.c

* bug fix edge condition during reseed on NUMA systems

* enable stuck test during early boot

* When waiting for "good" random numbers, the following concept applies:
        - kernel space: reaching the minimally seeded level triggers wakeup
        - user space: reaching the fully seeded level triggers wakeup

* Use RDSEED for seeding operations and RDRAND as a fallback as suggested by
  DJ Johnston (note, the final fallback to use a high-resolution timer is
  implicitly present by using the time stamp unconditional for each reseed).

* conserve entropy in output function of primary DRNG

Stephan Mueller (4):
  crypto: make Jitter RNG directly accessible
  random: conditionally compile code depending on LRNG
  Linux Random Number Generator
  LRNG - enable compile

 crypto/jitterentropy.c         |   33 +-
 drivers/char/Kconfig           |   10 +
 drivers/char/Makefile          |   10 +-
 drivers/char/lrng_base.c       | 2297 ++++++++++++++++++++++++++++++++++++++++
 drivers/char/lrng_chacha20.c   |  291 +++++
 include/crypto/jitterentropy.h |   80 ++
 include/linux/genhd.h          |    5 +
 7 files changed, 2694 insertions(+), 32 deletions(-)
 create mode 100644 drivers/char/lrng_base.c
 create mode 100644 drivers/char/lrng_chacha20.c
 create mode 100644 include/crypto/jitterentropy.h


Reply via email to