/dev/random - a new approach with full SP800-90B compliance

Hi,

The following patch set provides a different approach to /dev/random which is called Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the existing /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 testable.

The LRNG patch set allows a user to select use of the existing /dev/random or the LRNG during compile time. As the LRNG provides API and ABI compatible interfaces to the existing /dev/random implementation, the user can freely chose the RNG implementation without affecting kernel or user space operations.

This patch set provides early boot-time entropy which implies that no additional flags to the getrandom(2) system call discussed recently on the LKML is considered to be necessary.

The LRNG is fully compliant to SP800-90B requirements and is shipped with a full SP800-90B assessment and all required test tools. The existing /dev/random implementation on the other hand has architectural limitations which does not easily allow to bring the implementation in compliance with SP800-90B. The key statement that causes concern is SP800-90B section 3.1.6. This section denies crediting entropy to multiple similar noise sources. This section explicitly references different noise sources resting on the timing of events and their derivatives (i.e. it is a direct complaint to the existing existing /dev/random implementation). Therefore, SP800-90B now denies the very issue mentioned in [1] with the existing /dev/random implementation for a long time: crediting entropy to interrupts as well as crediting entropy to derivatives of interrupts (HID and disk events). This is not permissible with SP800-90B.

SP800-90B specifies various requirements for the noise source(s) that seed any DRNG including SP800-90A DRBGs. In about a year from now, SP800-90B will be mandated for all noise sources that provide entropy to DRBGs as part of a FIPS 140-[2|3] validation or other evaluation types. That means, if we there are no solutions to comply with the requirements of SP800-90B found till one year from now, any random number generation and ciphers based on random numbers on Linux will be considered and treated as not applicable and delivering no entropy! As /dev/urandom, getrandom(2) and /dev/random are the most common and prevalent noise sources for DRNGs, all these DRNGs are affected. This applies across the board for all validations of cryptography executing on Linux (kernel and user space modules).

For users that are not interested in SP800-90B, the entire code for the compliance as well as test interfaces can be deselected at compile time.

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

The LRNG provides a complete separation of the noise source maintenance and the collection of entropy into an entropy pool from the post-processing using a pseudo-random number generator. Different DRNGs are supported, including:

* The LRNG can be compile-time enabled to replace the existing /dev/random implementation. When not selecting the LRNG at compile time (default), the existing /dev/random implementation is built.

* Built-in ChaCha20 DRNG which has no dependency to other kernel frameworks.

* SP800-90A DRBG using the kernel crypto API including its accelerated raw cipher implementations. This implies that the output of /dev/random, getrandom(2), /dev/urandom or get_random_bytes is fully compliant to SP800-90A.

* Arbitrary DRNGs registered with the kernel crypto API

* Full compliance with SP800-90B which covers the startup and runtime health tests mandated by SP800-90B as well as providing the test tools and test interfaces to obtain raw noise data securely. The test tools are provided at [1].

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.

Compared to the existing /dev/random implementation, the compiled binary is smaller when the LRNG is compiled with all options equal to the existing /dev/random (i.e. only CONFIG_LRNG and CONFIG_LRNG_TRNG_SUPPORT are set): random.o is 52.5 kBytes whereas all LRNG object files are in 49 kBytes in size. The fully SP800-90A/SP800-90B compliant binary code (CONFIG_LRNG, CONFIG_LRNG_DRNG_SWITCH, CONFIG_LRNG_DRBG, CONFIG_LRNG_HEALTH_TESTS) uses some 61 kBytes.

[1] http://www.chronox.de/lrng.html - If the patch is accepted, I would be volunteering to convert the documentation into RST format and contribute it to the Linux kernel documentation directory.

Changes (compared to the previous patch set for 5.2):

* breakup of the monolithic code base into several logically isolated files and move all files into drivers/char/lrng/ - this also reduces the number of ifdefs in the code significantly as the make system is used to select the enabled code

* Add Tested-by and Reviewed-by lines

* Significant speedup of code executing in interrupt handler: the LRNG is now almost 50% faster as the existing /dev/random. On one example system, the LRNG interrupt handling code executes within an average of 65 cycles whereas the existing /dev/random on the same device takes about 97 cycles.

* SP800-90B compliance
- use hash_df function defined in SP800-90A section 10.3.1 to read entropy pool
- add compile time configurable SP800-90B health tests and eliminate any FIPS 140-2 code from the base code
- consider entropy reduction of conditioning operation compliant to SP800-90B
- complete entropy assessment and entropy assessment tests available at [1]

* prune base LRNG code of any FIPS-related code - all FIPS-related code is in the SP800-90B compliance code that can be deactivated at compile time

* testing performed with all tests offered at [1] including all required SP800-90B tests, as well as KASAN, UBSAN, and lockdep while executing stress tests. Tests were performed on: x86, S390

* make DRNG switching support compile-time configurable

* selection of entropy pool size is now a configure option

* support deactivation of TRNG (i.e. blocking behavior of /dev/random) at compile time. If deactivated, /dev/random behaves like getrandom(2).

* conditionally compile NUMA support

* eliminate in_atomic() invocation: In-kernel consumers always use the ChaCha20 DRNG unless the new API call get_random_bytes_full is invoked which may sleep but offer access to the full functionality of the LRNG including all types of DRNG.

* use debugfs file for obtaining raw entropy test data required to fulfill SP800-90B requirements

* fix: ensure that gathering raw entropy does not affect runtime of the kernel

* fix: import upstream patch b7d5dc21072cda7124d13eae2aefb7343ef94197

* fix: import upstream patch 428826f5358c922dc378830a1717b682c0823160

* fix: integrate patch "random: Don't freeze in add_hwgenerator_randomness() if stopping kthread"

* documentation enhancement: import upstream patch 92e507d216139b356a375afbda2824e85235e748 into documentation to cover all interfaces of the LRNG

* speedup of injection of non-aligned data into entropy pool

As a side node: With the switchable DRNG support offered in this patch set, the following areas could be removed. As the existing /dev/random has no support for switchable DRNGs, however, this is not yet feasible though.

* remove lrng_ready_list and all code around it in lrng_interfaces.c

* remove the kernel crypto API RNG API to avoid having two random number providing APIs - this would imply that all RNGs developed for this API would be converted to the LRNG interface

Stephan Mueller (12):
Linux Random Number Generator
LRNG - allocate one SDRNG instance per NUMA node LRNG - /proc interface
LRNG - add switchable DRNG support
crypto: DRBG - externalize DRBG functions for LRNG LRNG - add SP800-90A DRBG extension
LRNG - add kernel crypto API PRNG extension
crypto: provide access to a static Jitter RNG state LRNG - add Jitter RNG fast noise source LRNG - add TRNG support
LRNG - add SP800-90B compliance
LRNG - add interface for gathering of raw entropy

 MAINTAINERS                         |   7 +
 crypto/drbg.c                       |  16 +-
 crypto/jitterentropy.c              |  23 +
 drivers/char/Kconfig                |   2 +
 drivers/char/Makefile               |   9 +-
 drivers/char/lrng/Kconfig           | 145 ++++++
 drivers/char/lrng/Makefile          |  19 +
 drivers/char/lrng/lrng_archrandom.c | 105 +++++
 drivers/char/lrng/lrng_aux.c        | 161 +++++++
 drivers/char/lrng/lrng_chacha20.c   | 341 ++++++++++++++
 drivers/char/lrng/lrng_drbg.c       | 274 +++++++++++
 drivers/char/lrng/lrng_health.c     | 424 ++++++++++++++++++
 drivers/char/lrng/lrng_interfaces.c | 648 ++++++++++++++++++++++++++
 drivers/char/lrng/lrng_internal.h   | 322 +++++++++++++
 drivers/char/lrng/lrng_jent.c       | 101 +++++
 drivers/char/lrng/lrng_kcapi.c      | 341 ++++++++++++++
 drivers/char/lrng/lrng_numa.c       | 114 +++++
 drivers/char/lrng/lrng_pool.c       | 673 ++++++++++++++++++++++++++++
 drivers/char/lrng/lrng_proc.c       | 192 ++++++++
 drivers/char/lrng/lrng_sdrng.c      | 458 +++++++++++++++++++
 drivers/char/lrng/lrng_sw_noise.c   | 156 +++++++
 drivers/char/lrng/lrng_switch.c     | 198 ++++++++
 drivers/char/lrng/lrng_testing.c    | 324 +++++++++++++
 drivers/char/lrng/lrng_trng.c       | 301 +++++++++++++
 include/crypto/drbg.h               |   7 +
 include/linux/lrng.h                |  83 ++++
 26 files changed, 5437 insertions(+), 7 deletions(-)
 create mode 100644 drivers/char/lrng/Kconfig
 create mode 100644 drivers/char/lrng/Makefile
 create mode 100644 drivers/char/lrng/lrng_archrandom.c
 create mode 100644 drivers/char/lrng/lrng_aux.c
 create mode 100644 drivers/char/lrng/lrng_chacha20.c
 create mode 100644 drivers/char/lrng/lrng_drbg.c
 create mode 100644 drivers/char/lrng/lrng_health.c
 create mode 100644 drivers/char/lrng/lrng_interfaces.c
 create mode 100644 drivers/char/lrng/lrng_internal.h
 create mode 100644 drivers/char/lrng/lrng_jent.c
 create mode 100644 drivers/char/lrng/lrng_kcapi.c
 create mode 100644 drivers/char/lrng/lrng_numa.c
 create mode 100644 drivers/char/lrng/lrng_pool.c
 create mode 100644 drivers/char/lrng/lrng_proc.c
 create mode 100644 drivers/char/lrng/lrng_sdrng.c
 create mode 100644 drivers/char/lrng/lrng_sw_noise.c
 create mode 100644 drivers/char/lrng/lrng_switch.c
 create mode 100644 drivers/char/lrng/lrng_testing.c
 create mode 100644 drivers/char/lrng/lrng_trng.c
 create mode 100644 include/linux/lrng.h

2.23.0

In an effort to provide a flexible implementation for a random number generator that also delivers entropy during early boot time, allows replacement of the deterministic random number generation mechanism, implement the various components in separate code for easier maintenance, and provide compliance to SP800-90[A|B|C], introduce the Linux Random Number Generator (LRNG) framework.

The general design is as follows. Additional implementation details are given in [1]. The LRNG consists of the following components:

1. The LRNG may contain a True Random Number Generator (TRNG). The TRNG is a deterministic random number generator that is operated as a true random number generator. Using SP800-90A terminology, the TRNG is a DRBG with prediction resistance. The TRNG has a behavior similar to SP800-90A's concept of prediction resistance by only generating output when it is re-seeded with an equal amount of entropy. Every time a caller requests random numbers, the TRNG must be re-seeded with at least that amount of entropy from its noise sources. During boot time, the TRNG is not yet operated with prediction resistance. As the external interfaces to the TRNG to obtain random numbers start to be accessible after boot time completes, random numbers generated via these interfaces always access the TRNG that is operated with prediction resistance.

2. The LRNG implements a secondary DRNG. The secondary DRNG always generates the requested amount of output. When using the SP800-90A terminology it operates without prediction resistance. The secondary DRNG maintains a counter of how many bytes were generated since last re-seed and a timer of the elapsed time since last re-seed. If either the counter or the timer reaches a threshold, the secondary DRNG is seeded from the TRNG.

In case the Linux kernel detects a NUMA system, one secondary DRNG instance per NUMA node is maintained.

3. The TRNG is seeded by concatenating the data from the following sources:

(a) the output of the entropy pool,

(b) the Jitter RNG if available and enabled, and

(c) the CPU-based noise source such as Intel RDRAND if available and enabled.

The entropy estimate of the data of all noise sources are added to form the entropy estimate of the data used to seed the TRNG with. The LRNG ensures, however, that the TRNG after seeding is at maximum the security strength of the TRNG.

The LRNG is designed such that none of these noise sources can dominate the other noise sources to provide seed data to the TRNG during boot time due to the following:

(a) During boot time, the amount of received interrupts are the trigger points to (re)seed the TRNG.

(b) At runtime, the caller requesting random numbers from the primary TRNG drives the reseeding where always as much entropy as available is used to reseed the TRNG.

4. The entropy pool accumulates entropy obtained from certain events, which will henceforth be collectively called "slow noise sources". The entropy pool collects noise data from slow noise sources. Any data received by the LRNG from the slow noise sources is inserted into the entropy pool using an LFSR with a primitive and irreducible polynomial. The following sources of entropy are used:

(a) When an interrupt occurs, the high-resolution time stamp is mixed
into the LFSR. This time stamp is credited with heuristically implied entropy.

(b) HID event data like the key stroke or the mouse coordinates are
mixed into the LFSR. This data is not credited with entropy by the LRNG.

(c) Device drivers may provide data that is mixed into the LFSR. This
data is not credited with entropy by the LRNG.

(d) After the entropy pool is ``read'' by the TRNG, the data
used to seed the TRNG is mixed back into the entropy pool to stir the pool. This data is not credited with entropy by the LRNG.

Any data provided from user space by either writing to /dev/random, /dev/urandom or the IOCTL of RNDADDENTROPY on both device files are always injected into the entropy pool.

In addition, when a hardware random number generator covered by the Linux kernel HW generator framework wants to deliver random numbers, it is injected into the entropy pool as well. HW generator noise source is handled separately from the other noise source due to the fact that the HW generator framework may decide by itself when to deliver data whereas the other noise sources always requested for data driven by the LRNG operation. Similarly any user space provided data is inserted into the entropy pool.

When the TRNG requires data from the entropy pool, the entire entropy pool is processed with an SP800-90A section 10.3.1 compliant hash_df function to generate random numbers.

To speed up the interrupt handling code of the LRNG, the time stamp collected for an interrupt event is truncated to the 8 least significant bits. 64 truncated time stamps are concatenated and then jointly inserted into the LFSR. During boot time, until the fully seeded stage is reached, each time stamp with its 32 least significant bits is inserted into the LFSR at the time of arrival.

The LRNG allows the TRNG and secondary DRNG mechanism to be changed at runtime. Per default, a ChaCha20-based DRNG is used. The ChaCha20-DRNG implemented for the LRNG is also provided as a stand-alone user space deterministic random number generator. The LRNG also offers an SP800-90A DRBG based on the Linux kernel crypto API DRBG implementation.

The DRNG allows two methods of obtaining random data:

* For users requiring random numbers from a seeded and frequently reseeded secondary DRNG, such as the /dev/urandom, the getrandom system call or the in-kernel get_random_bytes function, the secondary DRNG is accessed directly by invoking its generate function. This generate function complies with the generate function discussed in SP800-90A.

* Users requiring random data that contains information theoretical entropy, such as for seeding other DRNGs also use the TRNG's generate function via the /dev/random device file and the getrandom system call when invoked with GRND_RANDOM. The difference to the /dev/urandom handling is that:

1. each TRNG generate request is limited to the amount of entropy
the of the DRNG was seeded with, and

2. each TRNG generate request is preceded by a reseeding of the
DRNG to implement a TRNG / a DRNG with prediction resistance.

The processing of entropic data from the noise source before injecting them into the TRNG is performed with the following mathematical operations:

1. LFSR: The 8 least significant bits of the time stamp data received from the interrupts are processed with an LFSR. That LFSR is implemented identically to the LSFR used in the existing /dev/random implementation except that it is capable of processing an entire word and that a different polynomial is used. The reason for the different polynomial is performance in a performance sensitive code section, the interrupt handler. The chosen polynomials have 4 taps. Also, this LFSR-approach is used in the OpenBSD /dev/random equivalent.

2. Concatenation: The temporary seed buffer used to seed the TRNG is a concatenation of parts of the entropy pool data, and the CPU noise source output.

The TRNG always tries to seed itself with 256 bits of entropy, except during boot. In any case, if the noise sources cannot deliver that amount, the available entropy is used and the TRNG keeps track on how much entropy it was seeded with. The entropy implied by the LRNG available in the entropy pool may be too conservative. To ensure that during boot time all available entropy from the entropy pool is transferred to the TRNG, the hash_df function always generates 256 data bits during boot to seed the TRNG. Yet, the TRNG entropy estimate is only increased by the amount of entropy the LRNG assumes to be present in that data. During boot, the TRNG is seeded as follows:

1. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if the entropy pool has collected at least 32 bits of entropy from the interrupt noise source. The goal of this step is to ensure that the primary and secondary DRNG receive some initial entropy as early as possible. In addition it receives the entropy available from the fast noise sources.

2. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if all noise sources collectively can provide at least 128 bits of entropy.

3. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if all noise sources collectivel can provide at least 256 bits.

At the time of the reseeding steps, the DRNG requests as much entropy as is available in order to skip certain steps and reach the seeding level of 256 bits. This may imply that one or more of the aforementioned steps are skipped.

In all listed steps, the secondary DRNG is (re)seeded with a number of random bytes from the TRNG that is equal to the amount of entropy the TRNG was seeded with. This means that when the TRNG is seeded with 128 or 256 bits of entropy, the secondary DRNG is seeded with that amount of entropy as well. There is only one exception to that rule: during initialization before the seed level of 128 bits is reached, a random number with 128 bit is generated by the TRNG to seed the secondary DRNG.

Before the TRNG is seeded with 256 bits of entropy in step 3, requests of random data from /dev/random are not processed.

At runtime, the TRNG delivers only random bytes equal to the entropy amount it was seeded with. E.g. if the TRNG was seeded with 128 bits of entropy, it will return only 128 bits of random data. Subsequent requests for random data are only fulfilled after a reseeding operation of the TRNG.

The TRNG will always require that all entropy sources collectively can deliver at least as many entropy bits as configured with /proc/sys/kernel/random/read_wakeup_threshold, i.e. per default 129 bits (128 bits of entropy for seeding plus one bit of entropy that is lost with the post processing as defined in SP800-90B).

The secondary DRNG operates as deterministic random number generator with the following properties:

* The maximum number of random bytes that can be generated with one DRNG generate operation is limited to 4096 bytes. When longer random numbers are requested, multiple DRNG generate operations are performed. The ChaCha20 DRNG as well as the SP800-90A DRBGs implement an update of their state after completing a generate request for backtracking resistance.

* The secondary DRNG is reseeded with whatever entropy is available – in the worst case where no additional entropy can be provided by the noise sources, the DRNG is not re-seeded and continues its operation to try to reseed again after again the expiry of one of these thresholds:

- If the last reseeding of the secondary DRNG is more than 600 seconds ago, or

- 2^20 DRNG generate operations are performed, whatever comes first, or

- the secondary DRNG is forced to reseed before the next generation of random numbers if data has been injected into the LRNG by writing data into /dev/random or /dev/urandom.

The chosen values prevent high-volume requests from user space to cause frequent reseeding operations which drag down the performance of the DRNG.

When the secondary DRNG requests a reseeding from the TRNG and the TRNG pulls from the entropy pool, an emergency entropy level of 512 bits of entropy is left in the entropy pool. This emergency entropy is provided to serve /dev/random even while /dev/urandom is stressed.

With the automatic reseeding after 600 seconds, the LRNG is triggered to reseed itself before the first request after a suspend that put the hardware to sleep for longer than 600 seconds.

The TRNG may not be compiled. In this case, the aforementioned statements covering the TRNG are not applicable. The secondary DRNG is seeded directly from the entropy pool just like the TRNG would have been seeded.

The LRNG has the following properties:

* internal noise source: interrupts timing with fast boot time seeding

* high performance of interrupt handling code: The LRNG impact on the interrupt handling has been reduced to a minimum. On one example system, the LRNG interrupt handling code executes within an average of 65 cycles whereas the existing /dev/random on the same device takes about 97 cycles when measuring the execution time of add_interrupt_randomness().

* lockless LFSR to collect raw entropy

* use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time

* "atomic" seeding of secondary DRBG to ensure full entropy transport

* instantiate one DRNG per NUMA node

* support for runtime switchable output DRNGs

* support for TRNG deactivation: The LRNG supports the compile-time deactivation of the TRNG (i.e. the blocking behavior of /dev/random). If deactivated, /dev/random operates like getrandom(2). This is intended to cover the recent discussions about removing the blocking_pool from the existing random.c.

* use of only well-defined entropy-preserving operations to collect, compress and forward entropy: concatenation, LFSR, SP800-90A hash_df function

* compile-time selectable entropy pool size: the choice also uses the applicable LFSR polynomial to maintain the entropy pool size

Further details including the rationale for the design choices and properties of the LRNG together with testing is provided at [1]. In addition, the documentation explains the conducted regression tests to verify that the LRNG is API and ABI compatible with the existing /dev/random implementation.

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

CC: "Eric W. Biederman" <[email protected]>
CC: "Alexander E. Patrakov" <[email protected]>
CC: "Ahmed S. Darwish" <[email protected]>
CC: "Theodore Y. Ts'o" <[email protected]>
CC: Willy Tarreau <[email protected]>
CC: Matthew Garrett <[email protected]>
CC: Vito Caputo <[email protected]>
CC: Andreas Dilger <[email protected]>
CC: Jan Kara <[email protected]>
CC: Ray Strode <[email protected]>
CC: William Jon McCann <[email protected]>
CC: zhangjs <[email protected]>
CC: Andy Lutomirski <[email protected]>
CC: Florian Weimer <[email protected]>
CC: Lennart Poettering <[email protected]>
CC: Nicolai Stange <[email protected]>
Mathematical aspects Reviewed-by: "Peter, Matthias" <[email protected]>

---
 MAINTAINERS                         |   7 +
 drivers/char/Kconfig                |   2 +
 drivers/char/Makefile               |   9 +-
 drivers/char/lrng/Kconfig           |  55 +++
 drivers/char/lrng/Makefile          |   9 +
 drivers/char/lrng/lrng_archrandom.c | 105 +++++
 drivers/char/lrng/lrng_aux.c        | 161 +++++++
 drivers/char/lrng/lrng_chacha20.c   | 341 ++++++++++++++
 drivers/char/lrng/lrng_interfaces.c | 649 +++++++++++++++++++++++++++
 drivers/char/lrng/lrng_internal.h   | 313 +++++++++++++
 drivers/char/lrng/lrng_pool.c       | 673 ++++++++++++++++++++++++++++
 drivers/char/lrng/lrng_sdrng.c      | 458 +++++++++++++++++++
 drivers/char/lrng/lrng_sw_noise.c   | 156 +++++++
 include/linux/lrng.h                |  83 ++++
 14 files changed, 3020 insertions(+), 1 deletion(-)
 create mode 100644 drivers/char/lrng/Kconfig
 create mode 100644 drivers/char/lrng/Makefile
 create mode 100644 drivers/char/lrng/lrng_archrandom.c
 create mode 100644 drivers/char/lrng/lrng_aux.c
 create mode 100644 drivers/char/lrng/lrng_chacha20.c
 create mode 100644 drivers/char/lrng/lrng_interfaces.c
 create mode 100644 drivers/char/lrng/lrng_internal.h
 create mode 100644 drivers/char/lrng/lrng_pool.c
 create mode 100644 drivers/char/lrng/lrng_sdrng.c
 create mode 100644 drivers/char/lrng/lrng_sw_noise.c
 create mode 100644 include/linux/lrng.h

index cba1095547fd..7232989d3a1c 100644
@@ -9488,6 +9488,13 @@ F:	Documentation/core-api/atomic_ops.rst
 F:	Documentation/core-api/refcount-vs-atomic.rst
 F:	Documentation/memory-barriers.txt
 
+LINUX RANDOM NUMBER GENERATOR (LRNG) DRIVER
+M:	Stephan Mueller <[email protected]>
+S:	Maintained
+W:	https://www.chronox.de/lrng.html
+F:	drivers/char/lrng/*
+F:	include/linux/lrng.h
+
 LIS3LV02D ACCELEROMETER DRIVER
 M:	Eric Piel <[email protected]>
 S:	Maintained

index df0fc997dc3e..cebb3a62c2ca 100644
@@ -535,6 +535,8 @@ config ADI
 	  and SSM (Silicon Secured Memory).  Intended consumers of this
 	  driver include crash and makedumpfile.
 
+source "drivers/char/lrng/Kconfig"
+
 endmenu
 
 config RANDOM_TRUST_CPU

index 7c5ea6f9df14..46ede09fd6d3 100644
@@ -3,7 +3,14 @@
 # Makefile for the kernel character device drivers.
 #
 
-obj-y				+= mem.o random.o
+obj-y				+= mem.o
+
+ifeq ($(CONFIG_LRNG),y)
+  obj-y				+= lrng/
+else
+  obj-y				+= random.o
+endif
+
 obj-$(CONFIG_TTY_PRINTK)	+= ttyprintk.o
 obj-y				+= misc.o
 obj-$(CONFIG_ATARI_DSP56K)	+= dsp56k.o

new file mode 100644
index 000000000000..2761623715d2
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the Linux Random Number Generator.
+#
+
+obj-y				+= lrng_pool.o lrng_aux.o \
+				   lrng_sw_noise.o lrng_archrandom.o \
+				   lrng_sdrng.o lrng_chacha20.o \
+				   lrng_interfaces.o \

2.23.0

Part of the diff is not shown here. View the raw message.

Stephan,

On Mon, 11 Nov 2019, Stephan Müller wrote:

thanks for Cc'ing me. I'll have a look at the technical details at later point in time. While skimming through the patches I noticed, that you thankfully added the SPDX license identifiers, but

Am Dienstag, 12. November 2019, 00:54:16 CET schrieb Thomas Gleixner:

Hi Thomas,

Thank you very much for considering a review.

Absolutely. I have removed that boiler plate disclaimer from all files.

Though I hope it is acceptable to wait for further comments before a resubmission.

Thank you very much.

Ciao
Stephan

Appreciated.

Of course!

Am Dienstag, 12. November 2019, 23:30:29 CET schrieb kbuild test robot:

Hi kbuild,

I need to include errno.h in lrng.h.

Thank you, it will be fixed in the next installment.

Ciao
Stephan

Am Mittwoch, 13. November 2019, 01:14:05 CET schrieb kbuild test robot:

Hi kbuild,

'add_interrupt_randomness':

Thank you for the report.

Both issues are fixed by including <asm/ptrace.h>.

This will be fixed with the next installment of the patch.

&reg_idx);

sizeof(u32));

Ciao
Stephan

As usual, some of your proposals make considerable sense to me & others do not, at least on first reading. I may have more comments after reflecting some.

Meanwhile, a couple of things jump out at me:

Why into the LFSR instead of into the entropy pool?

Why? This strikes me as pointless complication.

Assuming you do this without sacrificing the input mixing, this would be worth submitting as a separate patch. Saving cycles on every interrupt definitely looks worth doing.

This too.

Am Sonntag, 24. November 2019, 05:51:19 CET schrieb Sandy Harris:

Hi Sandy,

The LFSR is the state transitioning function of the entropy pool. Thus, when handing data to the LFSR, it is "mixed" into the entropy pool. Thus, the LRNG should perform the action you would expect, i.e. mixing the data into the entropy pool.

The reason for this is the construction definition of the German AIS 31.

The TRNG is considered to operate as an NTG.1 in the terms of AIS 31. The secondary DRNG(s) act as a DRG.3 in terms of AIS 31.

AIS 31 requires that DRGs (including a DRG.3) must be seeded from either an NTG.1 (i.e. the TRNG) or a PTG (a physical noise source which we do not have in the kernel).

This implies that the TRNG (NTG.1) seeds the secondary DRNG (DRG.3) and thus would be compliant to AIS 31.

Since this construction method does not violate other construction methods, such as the recommendations in SP800-90C, the LRNG architecture can be claimed to be compliant with multiple different construction methods and requirements where the output of either the TRNG or the secondary DRNGs always provide random data from a compliant RNG.

Note, this construction is only applied if the TRNG is selected and compiled. If the TRNG is not present (i.e. not compiled based on the Linux kernel compilation configuration), the secondary DRNGs seed directly from the entropy pool. Using this flexibility, the LRNG is intended to be able to serve different use cases and requirements.

For both comments, the issue is that patches should always provide code that compiles. The issue is that this logic cannot be extracted into a separate patch without sacrificing the requirement to make it compile.

Though, the code you refer to is extracted into its own C file which allows an independent assessment: please see lrng_sw_noise.c whose purpose is to only provide the high-performance interrupt handling code. The lockless LFSR is provided with the lrng_pool.c with the function lrng_pool_lfsr_u32.

PS: For those two functions and the ChaCha20 DRNG I have another patch in the pipeline that will add power-on self tests which are automatically executed during boot. Considering that these three functions are essential to the maintenance of entropy, adding the self test for those should provide additional assurance to users that the code runs properly.

PPS: If you want to study the operations of both, the high-performance interrupt collection and the lockless LFSR, there is user space test code that provides the implementation as a user space application: please see the test code in [1] and use the code in:

- lfsr_demonstration.c: Full operational LFSR to generate arbitrary amounts of data from arbitrary seed data.

- lfsr_testvector_generation.c: LFSR code that I used to generate self-test vectors for the pending patch

- time_storage.c: Test code for the high-performance interrupt handling code

In addition the essential ChaCha20 DRNG is available as a user space DRNG for study at [2].

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

[2] https://www.chronox.de/chacha20_drng.html

Thank you very much for your considerations.

Ciao
Stephan

In order to improve NUMA-locality when serving getrandom(2) requests, allocate one DRNG instance per node.

The SDRNG instance that is present right from the start of the kernel is reused as the first per-NUMA-node SDRNG. For all remaining online NUMA nodes a new SDRNG instance is allocated.

During boot time, the multiple SDRNG instances are seeded sequentially. With this, the first SDRNG instance (referenced as the initial SDRNG in the code) is completely seeded with 256 bits of entropy before the next SDRNG instance is completely seeded.

When random numbers are requested, the NUMA-node-local SDRNG is checked whether it has been already fully seeded. If this is not the case, the initial SDRNG is used to serve the request.

---
 drivers/char/lrng/Makefile        |   2 +
 drivers/char/lrng/lrng_internal.h |   5 ++
 drivers/char/lrng/lrng_numa.c     | 114 ++++++++++++++++++++++++++++++
 3 files changed, 121 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_numa.c

index 2761623715d2..a00cddb45773 100644
@@ -7,3 +7,5 @@ obj-y				+= lrng_pool.o lrng_aux.o \
 				   lrng_sw_noise.o lrng_archrandom.o \
 				   lrng_sdrng.o lrng_chacha20.o \
 				   lrng_interfaces.o \
+
+obj-$(CONFIG_NUMA)		+= lrng_numa.o

index 242f9b5b4f3d..e6ac2c527378 100644
@@ -263,8 +263,13 @@ int lrng_sdrng_get_sleep(u8 *outbuf, u32 outbuflen);
 void lrng_sdrng_force_reseed(void);
 void lrng_sdrng_seed_work(struct work_struct *dummy);
 
+#ifdef CONFIG_NUMA
+struct lrng_sdrng **lrng_sdrng_instances(void);
+void lrng_drngs_numa_alloc(void);
+#else	/* CONFIG_NUMA */
 static inline struct lrng_sdrng **lrng_sdrng_instances(void) { return NULL; }
 static inline void lrng_drngs_numa_alloc(void) { return; }
+#endif /* CONFIG_NUMA */
 
 /************************** Health Test linking code **************************/
 

2.23.0

The LRNG /proc interface provides the same files as the legacy /dev/random. These files behave identically. Yet, all files are documented at [1].

In addition, it provides the file lrng_type which provides details about the LRNG:

- is the TRNG present

- the name of the DRNG that produces the random numbers for /dev/random, /dev/urandom, getrandom(2)

- the hash used to produce random numbers from the entropy pool

- the number of secondary DRNG instances

- indicator whether the LRNG operates SP800-90B compliant

- indicator whether a high-resolution timer is identified - only with a high-resolution timer the interrupt noise source will deliver sufficient entropy

- indicator whether the LRNG has been minimally seeded (i.e. is the secondary DRNG seeded with at least 128 bits of of entropy)

- indicator whether the LRNG has been fully seeded (i.e. is the secondary DRNG seeded with at least 256 bits of entropy)

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

---
 drivers/char/lrng/Makefile          |   1 +
 drivers/char/lrng/lrng_interfaces.c |   1 -
 drivers/char/lrng/lrng_internal.h   |   4 +
 drivers/char/lrng/lrng_proc.c       | 192 ++++++++++++++++++++++++++++
 4 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 drivers/char/lrng/lrng_proc.c

index a00cddb45773..b6240b73e33d 100644
@@ -9,3 +9,4 @@ obj-y				+= lrng_pool.o lrng_aux.o \
 				   lrng_interfaces.o \
 
 obj-$(CONFIG_NUMA)		+= lrng_numa.o
+obj-$(CONFIG_SYSCTL)		+= lrng_proc.o

index e652849a1bdb..1c9517c6df4a 100644
@@ -56,7 +56,6 @@ static DECLARE_WAIT_QUEUE_HEAD(lrng_write_wait);
 static DECLARE_WAIT_QUEUE_HEAD(lrng_init_wait);
 static struct fasync_struct *fasync;
 
-struct ctl_table random_table[];
 /********************************** Helper ***********************************/
 
 /* Is the primary DRNG seed level too low? */

index e6ac2c527378..8528c2e8de88 100644
@@ -116,7 +116,11 @@ void lrng_cc20_init_state(struct chacha20_state *state);
 
 /********************************** /proc *************************************/
 
+#ifdef CONFIG_SYSCTL
+void lrng_pool_inc_numa_node(void);
+#else
 static inline void lrng_pool_inc_numa_node(void) { }
+#endif
 
 /****************************** LRNG interfaces *******************************/
 

2.23.0

The DRNG switch support allows replacing the DRNG mechanism of the LRNG. The switching support rests on the interface definition of include/linux/lrng.h. A new DRNG is implemented by filling in the interface defined in this header file.

In addition to the DRNG, the extension also has to provide a hash implementation that is used to hash the entropy pool for random number extraction.

Note: It is permissible to implement a DRNG whose operations may sleep. However, the hash function must not sleep.

The switchable DRNG support allows replacing the DRNG at runtime. However, only one DRNG extension is allowed to be loaded at any given time. Before replacing it with another DRNG implementation, the possibly existing DRNG extension must be unloaded.

The switchable DRNG extension activates the new DRNG during load time. It is expected, however, that such a DRNG switch would be done only once by an administrator to load the intended DRNG implementation.

It is permissible to compile DRNG extensions either as kernel modules or statically. The initialization of the DRNG extension should be performed with a late_initcall to ensure the extension is available when user space starts but after all other initialization completed. The initialization is performed by registering the function call data structure with the lrng_set_drng_cb function. In order to unload the DRNG extension, lrng_set_drng_cb must be invoked with the NULL parameter.

The DRNG extension should always provide a security strength that is at least as strong as LRNG_DRNG_SECURITY_STRENGTH_BITS.

---
 drivers/char/lrng/Kconfig       |   7 ++
 drivers/char/lrng/Makefile      |   1 +
 drivers/char/lrng/lrng_switch.c | 198 ++++++++++++++++++++++++++++++++
 3 files changed, 206 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_switch.c

index edf8be6aa0b1..a468d8292bac 100644
@@ -52,4 +52,11 @@ config LRNG_POOL_SIZE
 	default 4 if LRNG_POOL_SIZE_65536
 	default 5 if LRNG_POOL_SIZE_131072
 
+menuconfig LRNG_DRNG_SWITCH
+	bool "Support DRNG runtime switching"
+	help
+	  The Linux RNG per default uses a ChaCha20 DRNG that is
+	  accessible via the external interfaces. With this configuration
+	  option other DRNGs can be selected and loaded at runtime.
+
 endif # LRNG

index b6240b73e33d..6bac97638767 100644
@@ -10,3 +10,4 @@ obj-y				+= lrng_pool.o lrng_aux.o \
 
 obj-$(CONFIG_NUMA)		+= lrng_numa.o
 obj-$(CONFIG_SYSCTL)		+= lrng_proc.o
+obj-$(CONFIG_LRNG_DRNG_SWITCH)	+= lrng_switch.o

2.23.0

This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file.

---
 crypto/drbg.c         | 16 ++++++++++------
 include/crypto/drbg.h |  7 +++++++
 2 files changed, 17 insertions(+), 6 deletions(-)

index b6929eb5f565..5561dd0f09e1 100644
@@ -113,7 +113,7 @@
  * the SHA256 / AES 256 over other ciphers. Thus, the favored
  * DRBGs are the latest entries in this array.
  */
-static const struct drbg_core drbg_cores[] = {
+const struct drbg_core drbg_cores[] = {
 #ifdef CONFIG_CRYPTO_DRBG_CTR
 	{
 		.flags = DRBG_CTR | DRBG_STRENGTH128,

@@ -190,6 +190,7 @@ static const struct drbg_core drbg_cores[] = {
 	},
 #endif /* CONFIG_CRYPTO_DRBG_HMAC */
 };
+EXPORT_SYMBOL(drbg_cores);
 
 static int drbg_uninstantiate(struct drbg_state *drbg);
 

@@ -205,7 +206,7 @@ static int drbg_uninstantiate(struct drbg_state *drbg);
  * Return: normalized strength in *bytes* value or 32 as default
  *	   to counter programming errors
  */
-static inline unsigned short drbg_sec_strength(drbg_flag_t flags)
+unsigned short drbg_sec_strength(drbg_flag_t flags)
 {
 	switch (flags & DRBG_STRENGTH_MASK) {
 	case DRBG_STRENGTH128:

@@ -218,6 +219,7 @@ static inline unsigned short drbg_sec_strength(drbg_flag_t flags)
 		return 32;
 	}
 }
+EXPORT_SYMBOL(drbg_sec_strength);
 
 /*
  * FIPS 140-2 continuous self test for the noise source

@@ -1202,7 +1204,7 @@ static int drbg_seed(struct drbg_state *drbg, struct drbg_string *pers,
 }
 
 /* Free all substructures in a DRBG state without the DRBG state structure */
-static inline void drbg_dealloc_state(struct drbg_state *drbg)
+void drbg_dealloc_state(struct drbg_state *drbg)
 {
 	if (!drbg)
 		return;

@@ -1223,12 +1225,13 @@ static inline void drbg_dealloc_state(struct drbg_state *drbg)
 		drbg->fips_primed = false;
 	}
 }
+EXPORT_SYMBOL(drbg_dealloc_state);
 
 /*
  * Allocate all sub-structures for a DRBG state.
  * The DRBG state structure must already be allocated.
  */
-static inline int drbg_alloc_state(struct drbg_state *drbg)
+int drbg_alloc_state(struct drbg_state *drbg)
 {
 	int ret = -ENOMEM;
 	unsigned int sb_size = 0;

@@ -1307,6 +1310,7 @@ static inline int drbg_alloc_state(struct drbg_state *drbg)
 	drbg_dealloc_state(drbg);
 	return ret;
 }
+EXPORT_SYMBOL(drbg_alloc_state);
 
 /*************************************************************************
  * DRBG interface functions

@@ -1874,8 +1878,7 @@ static int drbg_kcapi_sym_ctr(struct drbg_state *drbg,
  *
  * return: flags
  */
-static inline void drbg_convert_tfm_core(const char *cra_driver_name,
-					 int *coreref, bool *pr)
+void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref, bool *pr)
 {
 	int i = 0;
 	size_t start = 0;

@@ -1902,6 +1905,7 @@ static inline void drbg_convert_tfm_core(const char *cra_driver_name,
 		}
 	}
 }
+EXPORT_SYMBOL(drbg_convert_tfm_core);
 
 static int drbg_kcapi_init(struct crypto_tfm *tfm)
 {

index 8c9af21efce1..c63b20375235 100644
@@ -282,4 +282,11 @@ enum drbg_prefixes {
 	DRBG_PREFIX3
 };
 
+extern int drbg_alloc_state(struct drbg_state *drbg);
+extern void drbg_dealloc_state(struct drbg_state *drbg);
+extern void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref,
+				  bool *pr);
+extern const struct drbg_core drbg_cores[];
+extern unsigned short drbg_sec_strength(drbg_flag_t flags);
+
 #endif /* _DRBG_H */

2.23.0

Using the LRNG switchable DRNG support, the SP800-90A DRBG extension is implemented.

The DRBG uses the kernel crypto API DRBG implementation. In addition, it uses the kernel crypto API SHASH support to provide the hashing operation.

The DRBG supports the choice of either a CTR DRBG using AES-256, HMAC DRBG with SHA-512 core or Hash DRBG with SHA-512 core. The used core can be selected with the module parameter lrng_drbg_type. The default is the CTR DRBG.

When compiling the DRBG extension statically, the DRBG is loaded at late_initcall stage which implies that with the start of user space, the user space interfaces of getrandom(2), /dev/random and /dev/urandom provide random data produced by an SP800-90A DRBG.

---
 drivers/char/lrng/Kconfig     |  11 ++
 drivers/char/lrng/Makefile    |   1 +
 drivers/char/lrng/lrng_drbg.c | 274 ++++++++++++++++++++++++++++++++++
 3 files changed, 286 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_drbg.c

index a468d8292bac..bf61e730e50f 100644
@@ -59,4 +59,15 @@ menuconfig LRNG_DRNG_SWITCH
 	  accessible via the external interfaces. With this configuration
 	  option other DRNGs can be selected and loaded at runtime.
 
+if LRNG_DRNG_SWITCH
+config LRNG_DRBG
+	tristate "SP800-90A support for the LRNG"
+	select CRYPTO_DRBG_MENU
+	select CRYPTO_CMAC if CRYPTO_DRBG_CTR
+	help
+	  Enable the SP800-90A DRBG support for the LRNG. Once the
+	  module is loaded, output from /dev/random, /dev/urandom,
+	  getrandom(2), or get_random_bytes is provided by a DRBG.
+endif # LRNG_DRNG_SWITCH
+
 endif # LRNG

index 6bac97638767..e3a704b3466c 100644
@@ -11,3 +11,4 @@ obj-y				+= lrng_pool.o lrng_aux.o \
 obj-$(CONFIG_NUMA)		+= lrng_numa.o
 obj-$(CONFIG_SYSCTL)		+= lrng_proc.o
 obj-$(CONFIG_LRNG_DRNG_SWITCH)	+= lrng_switch.o
+obj-$(CONFIG_LRNG_DRBG)		+= lrng_drbg.o

2.23.0

Add runtime-pluggable support for all PRNGs that are accessible via the kernel crypto API, including hardware PRNGs. The PRNG is selected with the module parameter drng_name where the name must be one that the kernel crypto API can resolve into an RNG.

This allows using of the kernel crypto API PRNG implementations that provide an interface to hardware PRNGs. Using this extension, the LRNG uses the hardware PRNGs to generate random numbers. An example is the S390 CPACF support providing such a PRNG.

The hash is provided by a kernel crypto API SHASH whose digest size complies with the seedsize of the PRNG.

---
 drivers/char/lrng/Kconfig      |  10 +
 drivers/char/lrng/Makefile     |   1 +
 drivers/char/lrng/lrng_kcapi.c | 341 +++++++++++++++++++++++++++++++++
 3 files changed, 352 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_kcapi.c

index bf61e730e50f..eb1cd63433dc 100644
@@ -68,6 +68,16 @@ config LRNG_DRBG
 	  Enable the SP800-90A DRBG support for the LRNG. Once the
 	  module is loaded, output from /dev/random, /dev/urandom,
 	  getrandom(2), or get_random_bytes is provided by a DRBG.
+
+config LRNG_KCAPI
+	tristate "Kernel Crypto API support for the LRNG"
+	select CRYPTO_RNG
+	help
+	  Enable the support for generic pseudo-random number
+	  generators offered by the kernel crypto API with the
+	  LRNG. Once the module is loaded, output from /dev/random,
+	  /dev/urandom, getrandom(2), or get_random_bytes is
+	  provided by the selected kernel crypto API RNG.
 endif # LRNG_DRNG_SWITCH
 
 endif # LRNG

index e3a704b3466c..027b6ea51c20 100644
@@ -12,3 +12,4 @@ obj-$(CONFIG_NUMA)		+= lrng_numa.o
 obj-$(CONFIG_SYSCTL)		+= lrng_proc.o
 obj-$(CONFIG_LRNG_DRNG_SWITCH)	+= lrng_switch.o
 obj-$(CONFIG_LRNG_DRBG)		+= lrng_drbg.o
+obj-$(CONFIG_LRNG_KCAPI)	+= lrng_kcapi.o

2.23.0

To support the LRNG operation which uses the Jitter RNG separately from the kernel crypto API, at a time where potentially the regular memory management is not yet initialized, the Jitter RNG needs to provide a state whose memory is defined at compile time. As only once instance will ever be needed by the LRNG, define once static memory block which is solely to be used by the LRNG.

---
 crypto/jitterentropy.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

index 77fa2120fe0c..3a815495f778 100644
@@ -644,3 +644,26 @@ int jent_entropy_init(void)
 
 	return 0;
 }
+
+struct rand_data *jent_lrng_entropy_collector(void)
+{
+	static unsigned char lrng_jent_mem[JENT_MEMORY_SIZE];
+	static struct rand_data lrng_jent_state = {
+		.data		= 0,
+		.old_data	= 0,
+		.prev_time	= 0,
+		.last_delta	= 0,
+		.last_delta2	= 0,
+		.osr		= 1,
+		.mem		= lrng_jent_mem,
+		.memlocation	= 0,
+		.memblocks	= JENT_MEMORY_BLOCKSIZE,
+		.memblocksize	= JENT_MEMORY_BLOCKS,
+		.memaccessloops	= JENT_MEMORY_ACCESSLOOPS,
+	};
+
+	if (jent_entropy_init())
+		return NULL;
+
+	return &lrng_jent_state;
+}

2.23.0

The Jitter RNG fast noise source implemented as part of the kernel crypto API is queried for 256 bits of entropy at the time the seed buffer managed by the LRNG is about to be filled.

---
 drivers/char/lrng/Kconfig     |  11 ++++
 drivers/char/lrng/Makefile    |   1 +
 drivers/char/lrng/lrng_jent.c | 101 ++++++++++++++++++++++++++++++++++
 3 files changed, 113 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_jent.c

index eb1cd63433dc..c6d26b88cdac 100644
@@ -80,4 +80,15 @@ config LRNG_KCAPI
 	  provided by the selected kernel crypto API RNG.
 endif # LRNG_DRNG_SWITCH
 
+config LRNG_JENT
+	bool "Enable Jitter RNG as LRNG Seed Source"
+	select CRYPTO_JITTERENTROPY
+	help
+	  The Linux RNG may use the Jitter RNG as noise source. Enabling
+	  this option enables the use of the Jitter RNG. Its default
+	  entropy level is 16 bits of entropy per 256 data bits delivered
+	  by the Jitter RNG. This entropy level can be changed at boot
+	  time or at runtime with the lrng_base.jitterrng configuration
+	  variable.
+
 endif # LRNG

index 027b6ea51c20..a87d800c9aae 100644
@@ -13,3 +13,4 @@ obj-$(CONFIG_SYSCTL)		+= lrng_proc.o
 obj-$(CONFIG_LRNG_DRNG_SWITCH)	+= lrng_switch.o
 obj-$(CONFIG_LRNG_DRBG)		+= lrng_drbg.o
 obj-$(CONFIG_LRNG_KCAPI)	+= lrng_kcapi.o
+obj-$(CONFIG_LRNG_JENT)		+= lrng_jent.o

2.23.0

The True Random Number Generator (TRNG) provides a random number generator with prediction resistance (SP800-90A terminology) or an NTG.1 (AIS 31 terminology).

When enabled, it obtains random numbers from the entropy pool and maintains the information with how much entropy it was seeded with. The TRNG only generates as much output data as it has as entropy.

The secondary DRNGs seed from the TRNG if it is present. In addition, the /dev/random device accesses the TRNG.

If the TRNG is disabled, the secondary DRNGs seed from the entropy pool and /dev/random behaves like getrandom(2).

The TRNG benefits from the switchable DRNG support which implies that data provided via /dev/random is generated by the loaded DRNG.

---
 drivers/char/lrng/Kconfig     |  22 +++
 drivers/char/lrng/Makefile    |   1 +
 drivers/char/lrng/lrng_trng.c | 301 ++++++++++++++++++++++++++++++++++
 3 files changed, 324 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_trng.c

index c6d26b88cdac..efc5f9aaa2a3 100644
@@ -91,4 +91,26 @@ config LRNG_JENT
 	  time or at runtime with the lrng_base.jitterrng configuration
 	  variable.
 
+config LRNG_TRNG_SUPPORT
+	bool "Enable True Random Number Generator support"
+	default y
+	help
+	  The true random number generator (TRNG) support, also
+	  known as DRNG with prediction resistance (SP800-90A
+	  terminology) or NTG.1 (AIS 31 terminology), generates
+	  random numbers after a successful reseed with entropy.
+	  Only when new entropy is provided for a new generation
+	  request, random data is provided with an equal amount
+	  as entropy was added. The TRNG is available via
+	  /dev/random.
+
+	  If the support is not enabled, /dev/random ensures that
+	  it received sufficient initial entropy and will produce
+	  random data without requiring a constant reseed with
+	  entropy. Yet it tries to regularly reseed itself with
+	  fresh entropy.
+
+	  With the TRNG support the /dev/random device will block
+	  if insufficient entropy is available.
+
 endif # LRNG

index a87d800c9aae..1c72bc060bce 100644
@@ -14,3 +14,4 @@ obj-$(CONFIG_LRNG_DRNG_SWITCH)	+= lrng_switch.o
 obj-$(CONFIG_LRNG_DRBG)		+= lrng_drbg.o
 obj-$(CONFIG_LRNG_KCAPI)	+= lrng_kcapi.o
 obj-$(CONFIG_LRNG_JENT)		+= lrng_jent.o
+obj-$(CONFIG_LRNG_TRNG_SUPPORT)	+= lrng_trng.o

2.23.0

Implement health tests for LRNG's slow noise sources as mandated by SP-800-90B The file contains the following health tests:

- stuck test: The stuck test calculates the first, second and third discrete derivative of the time stamp to be processed by the LFSR. Only if all three values are zero, the received time delta is considered to be non-stuck.

- SP800-90B Repetition Count Test (RCT): The LRNG uses an enhanced version of the RCT specified in SP800-90B section 4.4.1. Instead of counting identical back-to-back values, the input to the RCT is the counting of the stuck values during the processing of received interrupt events. The RCT is applied with alpha=2^-30 compliant to the recommendation of FIPS 140-2 IG 9.8. During the counting operation, the LRNG always calculates the RCT cut-off value of C. If that value exceeds the allowed cut-off value, the LRNG will trigger the health test failure discussed below. An error is logged to the kernel log that such RCT failure occurred. This test is only applied and enforced in FIPS mode, i.e. when the kernel compiled with CONFIG_CONFIG_FIPS is started with fips=1.

- SP800-90B Adaptive Proportion Test (APT): The LRNG implements the APT as defined in SP800-90B section 4.4.2. The assumed

The aforementioned health tests are applied to the first 1,024 time stamps obtained from interrupt events. In case one error is identified for either the RCT, or the APT, the collected entropy is invalidated and the SP800-90B startup health test is restarted.

As long as the SP800-90B startup health test is not completed, all LRNG random number output interfaces that may block will block and not generate any data. This implies that only those potentially blocking interfaces are defined to provide random numbers that are seeded with the interrupt noise source being SP800-90B compliant. All other output interfaces will not be affected by the SP800-90B startup test and thus are not considered SP800-90B compliant.

At runtime, the SP800-90B APT and RCT are applied to each time stamp generated for a received interrupt. When either the APT and RCT indicates a noise source failure, the LRNG is reset to a state it has immediately after boot:

- all entropy counters are set to zero

- the SP800-90B startup tests are re-performed which implies that getrandom(2) would block again until new entropy was collected

To summarize, the following rules apply:

• SP800-90B compliant output interfaces

- /dev/random

- getrandom(2) system call

- get_random_bytes kernel-internal interface when being triggered by the callback registered with add_random_ready_callback

• SP800-90B non-compliant output interfaces

- /dev/urandom

- get_random_bytes kernel-internal interface called directly

- randomize_page kernel-internal interface

- get_random_u32 and get_random_u64 kernel-internal interfaces

- get_random_u32_wait, get_random_u64_wait, get_random_int_wait, and get_random_long_wait kernel-internal interfaces

If either the RCT, or the APT health test fails irrespective whether during initialization or runtime, the following actions occur:

1. The entropy of the entire entropy pool is invalidated.

2. The primary and all secondary DRNGs are reset which imply that they are treated as being not seeded and require a reseed during next invocation.

3. The SP800-90B startup health test are initiated with all implications of the startup tests. That implies that from that point on, new events must be observed and its entropy must be inserted into the entropy pool before random numbers are calculated from the entropy pool.

Further details on the SP800-90B compliance and the availability of all test tools required to perform all tests mandated by SP800-90B are provided at [1].

The entire health testing code is compile-time configurable.

---
 drivers/char/lrng/Kconfig       |  13 +
 drivers/char/lrng/Makefile      |   1 +
 drivers/char/lrng/lrng_health.c | 424 ++++++++++++++++++++++++++++++++
 3 files changed, 438 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_health.c

index efc5f9aaa2a3..4373a1a19538 100644
@@ -113,4 +113,17 @@ config LRNG_TRNG_SUPPORT
 	  With the TRNG support the /dev/random device will block
 	  if insufficient entropy is available.
 
+config LRNG_HEALTH_TESTS
+	bool "Enable noise source online health tests"
+	help
+	  The online health tests validate the noise source at
+	  runtime for fatal errors. These tests include SP800-90B
+	  compliant tests which are invoked if the system is booted
+	  with fips=1. In case of fatal errors during active
+	  SP800-90B tests, the issue is logged and the noise
+	  data is discarded. These tests are required for full
+	  compliance with SP800-90B.
+
+	  If unsure, say Y.
+
 endif # LRNG

index 1c72bc060bce..0713e9c0aa6e 100644
@@ -15,3 +15,4 @@ obj-$(CONFIG_LRNG_DRBG)		+= lrng_drbg.o
 obj-$(CONFIG_LRNG_KCAPI)	+= lrng_kcapi.o
 obj-$(CONFIG_LRNG_JENT)		+= lrng_jent.o
 obj-$(CONFIG_LRNG_TRNG_SUPPORT)	+= lrng_trng.o
+obj-$(CONFIG_LRNG_HEALTH_TESTS)	+= lrng_health.o

2.23.0

11.11.2019 23:26, Stephan Müller пишет:

The other way round?

The sentence ends in the middle.

Alexander E. Patrakov

Am Dienstag, 12. November 2019, 20:58:32 CET schrieb Alexander E. Patrakov:

Hi Alexander,

Opps, yes, of course. If all three a non-zero...

Fixed.

Fixed:

"""
SP800-90B Adaptive Proportion Test (APT): The LRNG implements the
APT as defined in SP800-90B section 4.4.2. The applied significance level again is alpha=2^-30 compliant to the recommendation of FIPS 140-2 IG 9.8.
"""

I manually broke it for testing as follows: I set the LRNG_APT_CUTOFF to 1 to trigger the APT failure and I changed the line

if (rct_count >= 30) {

to

if (rct_count >= 1) {

which effectively sets the RCT cutoff value to 1.

Allow me to check how CONFIG_BROKEN really works to see how I can roll this test into CONFIG_BROKEN.

Thank you very much for your review.

Ciao
Stephan

Am Dienstag, 12. November 2019, 20:58:32 CET schrieb Alexander E. Patrakov:

Hi Alexander,

I am unable to find sensible information about CONFIG_BROKEN in the recent kernel tree.

Do you happen to have a pointer on how that option is to be used?

Thanks a lot

Ciao
Stephan

ср, 13 нояб. 2019 г. в 05:38, Stephan Müller <[email protected]>:

This option is not used on its own. You create a new option, CONFIG_TEST_LRNG_FAILURE_MODE or something like that, and put your code under the ifdef guarded by that option. And then, to prevent ordinary users and allyesconfig from selecting it, in Kconfig you say:
"depends on BROKEN". This way, the option becomes unselectable in menuconfig but still works as intended when added manually to .config (obviously, with the BROKEN dependency removed locally).

Definition: https://github.com/torvalds/linux/blob/9c7db5004280767566e91a33445bf93aa479ef02/init/Kconfig#L68
Example usage: https://github.com/torvalds/linux/blob/c87237110f2553b4200a8b3401a01198edfcf0d9/drivers/gpu/drm/i915/Kconfig.debug#L166

--
Alexander E. Patrakov

Am Mittwoch, 13. November 2019, 07:02:40 CET schrieb Alexander E. Patrakov:

Hi Alexander,

I added such support to the LRNG.

Thank you for your suggestion.

Ciao
Stephan

The test interface allows a privileged process to capture the raw unconditioned noise that is collected by the LRNG for statistical analysis. Extracted noise data is not used to seed the LRNG. This is a test interface and not appropriate for production systems. Yet, the interface is considered to be sufficiently secured for production systems.

Access to the data is given through the lrng_raw debugfs file. The data buffer should be multiples of sizeof(u32) to fill the entire buffer. Using the option lrng_testing.boot_test=1 the raw noise of the first 1000 entropy events since boot can be sampled.

This test interface allows generating the data required for analysis whether the LRNG is in compliance with SP800-90B sections 3.1.3 and 3.1.4.

---
 drivers/char/lrng/Kconfig        |  16 ++
 drivers/char/lrng/Makefile       |   1 +
 drivers/char/lrng/lrng_testing.c | 324 +++++++++++++++++++++++++++++++
 3 files changed, 341 insertions(+)
 create mode 100644 drivers/char/lrng/lrng_testing.c

index 4373a1a19538..c3d7524b7698 100644
@@ -126,4 +126,20 @@ config LRNG_HEALTH_TESTS
 
 	  If unsure, say Y.
 
+config LRNG_TESTING
+	bool "Enable entropy test interface to LRNG noise source"
+	select CONFIG_DEBUG_FS
+	help
+	  The test interface allows a privileged process to capture
+	  the raw unconditioned noise that is collected by the LRNG
+	  for statistical analysis. Extracted noise data is not used
+	  to seed the LRNG.
+
+	  The raw noise data can be obtained using the lrng_raw
+	  debugfs file. Using the option lrng_testing.boot_test=1
+	  the raw noise of the first 1000 entropy events since boot
+	  can be sampled.
+
+	  If unsure, say N.
+
 endif # LRNG

index 0713e9c0aa6e..c0b6cc4301fe 100644
@@ -16,3 +16,4 @@ obj-$(CONFIG_LRNG_KCAPI)	+= lrng_kcapi.o
 obj-$(CONFIG_LRNG_JENT)		+= lrng_jent.o
 obj-$(CONFIG_LRNG_TRNG_SUPPORT)	+= lrng_trng.o
 obj-$(CONFIG_LRNG_HEALTH_TESTS)	+= lrng_health.o
+obj-$(CONFIG_LRNG_TESTING)	+= lrng_testing.o

2.23.0

Am Dienstag, 12. November 2019, 21:55:10 CET schrieb kbuild test robot:

Hi kbuild,

__aligned(sizeof(u32));

This is the offending line.

I will need to kzalloc the code here.

Thank you.

Ciao
Stephan

* Stephan Müller:

I don't quite understand this comment. Doesn't getrandom with the GRND_RANDOM always behave like /dev/random? Presumably, without the TRNG tap, the GRND_RANDOM flag for getrandom is ignored, and reading from /dev/random behaves like reading from /dev/urandom.

Anyway, reading the accompanying PDF, this looks rather impressive:
the userspace bootstrapping problem is gone (the issue where waiting for more entropy prevents the collection of more entropy), *and* we can still make the standards people happy.

(Replying from my other account due to mail issues, sorry.)

Am Dienstag, 12. November 2019, 14:23:10 CET schrieb Florian Weimer:

Hi Florian,

Absolutely. Apologies for the imprecision here. I will correct that.

The idea is that the constant blocking behavior of /dev/random and GRND_RANDOM is replaced with the blocking behavior of getrandom(2) without the GRND_RANDOM flag (i.e. the interface waits until the LRNG thinks it is completely seeded before it provides ulimited data).

Ciao
Stephan

This is very nice!

I'm uneasy about this. I fully believe that, *on x86*, this works. But on embedded systems with in-order CPUs, a single clock, and very lightweight boot processes, most or all of boot might be too deterministic for this to work.

I have a somewhat competing patch set here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=random/kill-it

(Ignore the "horrible test hack" and the debugfs part.)

The basic summary is that I change /dev/random so that it becomes functionally identical to getrandom(..., 0) -- in other words, it blocks until the CRNG is initialized but is then identical to /dev/urandom. And I add getrandom(...., GRND_INSECURE) that is functionally identical to the existing /dev/urandom: it always returns *something* immediately, but it may or may not actually be cryptographically random or even random at all depending on system details.

In other words, my series simplifies the ABI that we support. Right now, we have three ways to ask for random numbers with different semantics and we need to have to RNGs in the kernel at all time. With my changes, we have only two ways to ask for random numbers, and the /dev/random pool is entirely gone.

Would you be amenable to merging this into your series (i.e. either merging the code or just the ideas)? This would let you get rid of things like the compile-time selection of the blocking TRNG, since the blocking TRNG would be entirely gone.

Or do you think that a kernel-provided blocking TRNG is a genuinely useful thing to keep around?

--Andy

Am Dienstag, 12. November 2019, 16:33:59 CET schrieb Andy Lutomirski:

Hi Andy,

I agree that in such cases, my LRNG getrandom(2) would also block until the LRNG thinks it collected 256 bits of entropy. However, I am under the impression that the LRNG collects that entropy faster that the existing /dev/ random implementation, even in this case.

Nicolai is copied on this thread. He promised to have the LRNG tested on such a minimalistic system that you describe. I hope he could contribute some numbers from that test helping us to understand how much of a problem we face.

This would be equal to the LRNG code without compiling the TRNG.

Ok, if it is suggested that getrandom(2) should also have a mode to behave exactly like /dev/urandom by not waiting until it is fully seeded, I am happy to add that.

Again, I do not want to stand in the way of changing the ABI if this is the agreed way. All I want to say is that the LRNG seemingly is initialized much faster than the existing /dev/random. If this is not fast enough for some embedded environments, I would not want to stand in the way to make their life easier.

Absolutely. I would be happy to do that.

Allow me to pull your code (I am currently behind a slow line) and review it to see how best to integrate it.

Hm, I am not so sure we should do that.

Allow me to explain: I am also collaborating on the European side with the German BSI. They love /dev/random as it is a "NTG.1" RNG based on their AIS 31 standard.

In order to seed a deterministic RNG (like OpenSSL, GnuTLS, etc. which are all defined to be "DRG.3" or "DRG.2"), BSI mandates that the seed source is an NTG.1.

By getting rid of the TRNG entirely and having /dev/random entirely behaving like /dev/urandom or getrandom(2) without the GRND_RANDOM flag, the kernel would "only" provide a "DRG.3" type RNG. This type of RNG would be disallowed to seed another "DRG.3" or "DRG.2".

In plain English that means that for BSI's requirements, if the TRNG is gone there would be no native seed source on Linux any more that can satisfy the requirement. This is the ultimate reason why I made the TRNG compile-time
selectable: to support embedded systems but also support use cases like the BSI case.

Please consider that I maintain a study over the last years for BSI trying to ensure that the NTG.1 property is always met [1] [2]. The sole purpose of that study is around this NTG.1.

Yes, as I hope I explained it appropriately above, there are standardization requirements that need the TRNG.

PS: When I was forwarding Linus' email on eliminating the blocking_pool to BSI, I saw unhappy faces. :-)

I would like to help both sides here.

[1] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/NTG1_Kerneltabelle_EN.pdf?__blob=publicationFile&v=3

[2] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/NTG1_Kerneltabelle_EN.pdf?__blob=publicationFile&v=3

Ciao
Stephan

Am Mittwoch, 13. November 2019, 00:03:47 CET schrieb Stephan Müller:

Hi Stephan,

Sorry, the copy did not work:

[2] https://bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile&v=16

Ciao
Stephan

Am Dienstag, 12. November 2019, 16:33:59 CET schrieb Andy Lutomirski:

Hi Andy,

I pulled your code and found the following based on my explanation that I would suggest to keep the TRNG at least as an option.

- 7d54ef8512b06baf396f12584f7f48a9558ecd0f does not seem applicable: I also do have an equivalent "lrng_init_wait" wait queue. This wait queue is used to let in-kernel users wait until the LRNG obtained 128 bits of entropy. In addition, this wait queue is used to let user space is invoked after the LRNG has received 256 bits of entropy (which implies that the kernel waiters are invoked earlier). In kernel waiters are all that call wait_for_random_bytes and its derivatives. User space callers have to call getrandom(..., 0); to be registered in this wait queue. So, I think the wakeup calls I have in the LRNG for lrng_init_wait should remain.

- 6a26a3146e5fb90878dca9fde8caa1ca4233156a: My handler for /dev/urandom and getrandom(..., 0) are using one callback which issues a warning in both use cases (see lrng_sdrng_read). So I think this patch may not be applicable as the LRNG code implements warning about being unseeded.

- 3e8e159da49b44ae0bb08e68fa2be760722fa033: I am happy to take that code which would almost directly apply. The last hunk however would be:

if (!(flags & GRND_INSECURE) && unlikely(!lrng_state_operational())) {

==> Shall I apply it to my code base? If yes, how shall the changes to random.h be handled?

- 920e97e7fc508e6f0da9c7dec94c8073fd63ab4d: I would pass on this patch due to the following: it unconditionally starts removing the access to the TRNG (the LRNG's logical equivalent to the blocking_pool). As patch 10/12 of the LRNG patch series provides the TRNG that is a compile time option, your patch would logically and functionally be equivalent when deselecting CONFIG_LRNG_TRNG_SUPPORT in the LRNG without any further changes to the LRNG code.

- 693b9ffdf0fdc93456b5ad293ac05edf240a531b: This patch is applicable to the LRNG. In case CONFIG_LRNG_TRNG_SUPPORT is not set, the TRNG is not present. Yet, the /dev/random and getrandom(GRND_RANDOM) would behave blocked until fully initialized. I have now added the general blocking until the LRNG is fully initialized to the common /dev/random and getrandom(GRND_RANDOM) interface function of lrng_trng_read_common. With that, the LRNG would be fully equivalent to this patch if CONFIG_LRNG_TRNG_SUPPORT is not set.

- 66f660842ec6d34134b9c3c1c9c65972834797f6: This patch is implicit with CONFIG_LRNG_TRNG_SUPPORT being not set.

- d8f59b5c25af22fb9d85b7fa96de601ea03f2eac: This patch is not applicable to the LRNG as the deactivation of CONFIG_LRNG_TRNG_SUPPORT implies that there should be no unused code left in the LRNG.

- 4046ac638761821aef67af10537ebcbc80715785: In theory that patch is applicable to the LRNG as well. The LRNG has the lrng_read_wait queue. If CONFIG_LRNG_TRNG_SUPPORT is not set, there will never be the code triggered to add a caller to this wait queue. To avoid cluttering the LRNG code with ifdefs, may I suggest to leave these several lines even though it is dead code?

Bottom line: the only patch that I seems to be relevant and that I would be happy to apply is the one adding GRND_INSECURE. All other patches are implicitly covered by deselecting CONFIG_LRNG_TRNG_SUPPORT.

By making the TRNG compile-time selectable, I was hoping to serve all users: I wanted to cover the conclusions of the discussion to remove the blocking_pool. On the other hand, however, I want to support requirements that need the blocking behavior.

The current LRNG patch set, however, defaults to Y for CONFIG_LRNG_TRNG_SUPPORT. I would see no issue if it defaults to N.

Thank you very much.

Ciao
Stephan

Not surprising. It's just a cleanup to the existing code, and I doubt you inherited the oddity I'm fixing.

Probably true.

What is the actual semantics of /dev/urandom with your series applied?
Is there any situation in which it will block?

This might be a question for Ted. Once the merge window opens, I'll resubmit it.

Given your previous email about the TRNG, I'm wondering what the API for the TRNG should be. I am willing to grant that there are users who need a TRNG for various reasons, and that not all of them can use hwrng. (And the current hwrng API is pretty bad.) But I'm not convinced that /dev/random or getrandom(..., GRND_RANDOM) is a reasonable way to access it. A blocking_pool-style TRNG is a very limited resource, and I think it could make sense to require some sort of actual permission to use it. GRND_RANDOM has no access control at all, and everyone expects /dev/random to be world-readable. The most widespread user of /dev/random that I know of is gnupg, and gnupg really should not be using it.

Would it make sense to have a /dev/true_random that is 0400 by default for users who actually need it? Then /dev/random and GRND_RANDOM could work as they do with my patch, and maybe it does the right thing for everyone.

Sounds reasonable.

I find it odd that /dev/random would be either a TRNG or not a TRNG depending on kernel configuration. For the small fraction of users that actually want a TRNG, wouldn't it be better to have an interface that fails outright if the TRNG is not enabled?

--Andy

Am Mittwoch, 13. November 2019, 05:48:30 CET schrieb Andy Lutomirski:

Hi Andy,

The LRNG tries to provide a 100% identical user interface to the existing / dev/random:

- /dev/urandom never blocks

- getrandom(..., 0) blocks until the LRNG has received 256 bits of entropy (i.e. the LRNG is fully seeded)

Yet, both may issue a warning if CONFIG_WARN_ALL_UNSEEDED_RANDOM is set.

Ok, I will keep it out of the LRNG for now, but once your patch is merged, I would integrate it.

That is surely a reasonable way to do it. But I am not sure 0400 should be applied, but rather 0440. This should allow introducing a group in user space that processes who need the TRNG are not required to have root privilege, but rather need to be a member of some otherwise unprivileged group.

Sure, I would have no concerns here.

Ciao
Stephan

Hi,

The following patch set provides a different approach to /dev/random which is called Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the existing /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 testable.

The LRNG patch set allows a user to select use of the existing /dev/random or the LRNG during compile time. As the LRNG provides API and ABI compatible interfaces to the existing /dev/random implementation, the user can freely chose the RNG implementation without affecting kernel or user space operations.

This patch set provides early boot-time entropy which implies that no additional flags to the getrandom(2) system call discussed recently on the LKML is considered to be necessary. Yet, if additional flags are introduced to cover special hardware, the LRNG implementation will also provide them to be fully ABI and API compliant as already discussed on LKML.

The LRNG is fully compliant to SP800-90B requirements and is shipped with a full SP800-90B assessment and all required test tools. The existing /dev/random implementation on the other hand has architectural limitations which does not easily allow to bring the implementation in compliance with SP800-90B. The key statement that causes concern is SP800-90B section 3.1.6. This section denies crediting entropy to multiple similar noise sources. This section explicitly references different noise sources resting on the timing of events and their derivatives (i.e. it is a direct complaint to the existing existing /dev/random implementation). Therefore, SP800-90B now denies the very issue mentioned in [1] with the existing /dev/random implementation for a long time: crediting entropy to interrupts as well as crediting entropy to derivatives of interrupts (HID and disk events). This is not permissible with SP800-90B.

SP800-90B specifies various requirements for the noise source(s) that seed any DRNG including SP800-90A DRBGs. In about a year from now, SP800-90B will be mandated for all noise sources that provide entropy to DRBGs as part of a FIPS 140-[2|3] validation or other evaluation types. That means, if we there are no solutions to comply with the requirements of SP800-90B found till one year from now, any random number generation and ciphers based on random numbers on Linux will be considered and treated as not applicable and delivering no entropy! As /dev/urandom, getrandom(2) and /dev/random are the most common and prevalent noise sources for DRNGs, all these DRNGs are affected. This applies across the board for all validations of cryptography executing on Linux (kernel and user space modules).

For users that are not interested in SP800-90B, the entire code for the compliance as well as test interfaces can be deselected at compile time.

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

The LRNG provides a complete separation of the noise source maintenance and the collection of entropy into an entropy pool from the post-processing using a pseudo-random number generator. Different DRNGs are supported, including:

* The LRNG can be compile-time enabled to replace the existing /dev/random implementation. When not selecting the LRNG at compile time (default), the existing /dev/random implementation is built.

* Built-in ChaCha20 DRNG which has no dependency to other kernel frameworks.

* SP800-90A DRBG using the kernel crypto API including its accelerated raw cipher implementations. This implies that the output of /dev/random, getrandom(2), /dev/urandom or get_random_bytes is fully compliant to SP800-90A.

* Arbitrary DRNGs registered with the kernel crypto API

* Full compliance with SP800-90B which covers the startup and runtime health tests mandated by SP800-90B as well as providing the test tools and test interfaces to obtain raw noise data securely. The test tools are provided at [1].

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.

Compared to the existing /dev/random implementation, the compiled binary is smaller when the LRNG is compiled with all options equal to the existing /dev/random (i.e. only CONFIG_LRNG and CONFIG_LRNG_TRNG_SUPPORT are set): random.o is 52.5 kBytes whereas all LRNG object files are in 49 kBytes in size. The fully SP800-90A/SP800-90B compliant binary code (CONFIG_LRNG, CONFIG_LRNG_DRNG_SWITCH, CONFIG_LRNG_DRBG, CONFIG_LRNG_HEALTH_TESTS) uses some 61 kBytes.

[1] http://www.chronox.de/lrng.html - If the patch is accepted, I would be volunteering to convert the documentation into RST format and contribute it to the Linux kernel documentation directory.

Changes (compared to the previous patch set):

* Remove of the boiler plate disclaimers as requested by Thomas Gleixner

* fix compile issues reported by kbuild: adding missing header files and turn large stack variable into a heap variable with lrng_testing.c

* fix patch descriptions as suggested by Florian Weimer and Alexander E. Patrakov

* remove stale comment in _lrng_sdrng_seed

* move blocking of /dev/random and getrandom(GRND_RANDOM) until LRNG is seeded to the interface handling code to simplify the code and to ensure the blocking is also enforced if the TRNG is not compiled.

* add BROKEN test support for SP800-90B adaptive proportion test and repetitive count test as suggested by Alexander E. Patrakov

A patch for adding power-up self tests is prepared but I did not want to add it now to support code review of a code base with minimal changes. It will be provided once the code review is completed. With this pending code, the following tests are available:

* power-on self test: LFSR self test

* power-on self test: ChaCha20 DRNG self test

* power-on self test: time stamp array handling in lrng_sw_noise.c

* power-on self test: SP800-90A DRBG self test

* runtime test: raw noise source data collection, if enabled

* separate test: SP800-90B APT and RCT test enforcement validation if enabled

As a side node: With the switchable DRNG support offered in this patch set, the following areas could be removed. As the existing /dev/random has no support for switchable DRNGs, however, this is not yet feasible though.

* remove lrng_ready_list and all code around it in lrng_interfaces.c

* remove the kernel crypto API RNG API to avoid having two random number providing APIs - this would imply that all RNGs developed for this API would be converted to the LRNG interface

Stephan Mueller (12):
Linux Random Number Generator
LRNG - allocate one SDRNG instance per NUMA node LRNG - /proc interface
LRNG - add switchable DRNG support
crypto: DRBG - externalize DRBG functions for LRNG LRNG - add SP800-90A DRBG extension
LRNG - add kernel crypto API PRNG extension
crypto: provide access to a static Jitter RNG state LRNG - add Jitter RNG fast noise source LRNG - add TRNG support
LRNG - add SP800-90B compliant health tests LRNG - add interface for gathering of raw entropy

 MAINTAINERS                         |   7 +
 crypto/drbg.c                       |  16 +-
 crypto/jitterentropy.c              |  23 +
 drivers/char/Kconfig                |   2 +
 drivers/char/Makefile               |   9 +-
 drivers/char/lrng/Kconfig           | 188 ++++++++
 drivers/char/lrng/Makefile          |  19 +
 drivers/char/lrng/lrng_archrandom.c |  92 ++++
 drivers/char/lrng/lrng_aux.c        | 148 +++++++
 drivers/char/lrng/lrng_chacha20.c   | 328 ++++++++++++++
 drivers/char/lrng/lrng_drbg.c       | 261 +++++++++++
 drivers/char/lrng/lrng_health.c     | 409 +++++++++++++++++
 drivers/char/lrng/lrng_interfaces.c | 647 +++++++++++++++++++++++++++
 drivers/char/lrng/lrng_internal.h   | 309 +++++++++++++
 drivers/char/lrng/lrng_jent.c       |  88 ++++
 drivers/char/lrng/lrng_kcapi.c      | 328 ++++++++++++++
 drivers/char/lrng/lrng_numa.c       | 101 +++++
 drivers/char/lrng/lrng_pool.c       | 660 ++++++++++++++++++++++++++++
 drivers/char/lrng/lrng_proc.c       | 179 ++++++++
 drivers/char/lrng/lrng_sdrng.c      | 436 ++++++++++++++++++
 drivers/char/lrng/lrng_sw_noise.c   | 144 ++++++
 drivers/char/lrng/lrng_switch.c     | 185 ++++++++
 drivers/char/lrng/lrng_testing.c    | 324 ++++++++++++++
 drivers/char/lrng/lrng_trng.c       | 283 ++++++++++++
 include/crypto/drbg.h               |   7 +
 include/linux/lrng.h                |  83 ++++
 26 files changed, 5269 insertions(+), 7 deletions(-)
 create mode 100644 drivers/char/lrng/Kconfig
 create mode 100644 drivers/char/lrng/Makefile
 create mode 100644 drivers/char/lrng/lrng_archrandom.c
 create mode 100644 drivers/char/lrng/lrng_aux.c
 create mode 100644 drivers/char/lrng/lrng_chacha20.c
 create mode 100644 drivers/char/lrng/lrng_drbg.c
 create mode 100644 drivers/char/lrng/lrng_health.c
 create mode 100644 drivers/char/lrng/lrng_interfaces.c
 create mode 100644 drivers/char/lrng/lrng_internal.h
 create mode 100644 drivers/char/lrng/lrng_jent.c
 create mode 100644 drivers/char/lrng/lrng_kcapi.c
 create mode 100644 drivers/char/lrng/lrng_numa.c
 create mode 100644 drivers/char/lrng/lrng_pool.c
 create mode 100644 drivers/char/lrng/lrng_proc.c
 create mode 100644 drivers/char/lrng/lrng_sdrng.c
 create mode 100644 drivers/char/lrng/lrng_sw_noise.c
 create mode 100644 drivers/char/lrng/lrng_switch.c
 create mode 100644 drivers/char/lrng/lrng_testing.c
 create mode 100644 drivers/char/lrng/lrng_trng.c
 create mode 100644 include/linux/lrng.h

2.23.0

In an effort to provide a flexible implementation for a random number generator that also delivers entropy during early boot time, allows replacement of the deterministic random number generation mechanism, implement the various components in separate code for easier maintenance, and provide compliance to SP800-90[A|B|C], introduce the Linux Random Number Generator (LRNG) framework.

The general design is as follows. Additional implementation details are given in [1]. The LRNG consists of the following components:

1. The LRNG may contain a True Random Number Generator (TRNG). The TRNG is a deterministic random number generator that is operated as a true random number generator. Using SP800-90A terminology, the TRNG is a DRBG with prediction resistance. The TRNG has a behavior similar to SP800-90A's concept of prediction resistance by only generating output when it is re-seeded with an equal amount of entropy. Every time a caller requests random numbers, the TRNG must be re-seeded with at least that amount of entropy from its noise sources. During boot time, the TRNG is not yet operated with prediction resistance. As the external interfaces to the TRNG to obtain random numbers start to be accessible after boot time completes, random numbers generated via these interfaces always access the TRNG that is operated with prediction resistance.

2. The LRNG implements a secondary DRNG. The secondary DRNG always generates the requested amount of output. When using the SP800-90A terminology it operates without prediction resistance. The secondary DRNG maintains a counter of how many bytes were generated since last re-seed and a timer of the elapsed time since last re-seed. If either the counter or the timer reaches a threshold, the secondary DRNG is seeded from the TRNG.

In case the Linux kernel detects a NUMA system, one secondary DRNG instance per NUMA node is maintained.

3. The TRNG is seeded by concatenating the data from the following sources:

(a) the output of the entropy pool,

(b) the Jitter RNG if available and enabled, and

(c) the CPU-based noise source such as Intel RDRAND if available and enabled.

The entropy estimate of the data of all noise sources are added to form the entropy estimate of the data used to seed the TRNG with. The LRNG ensures, however, that the TRNG after seeding is at maximum the security strength of the TRNG.

The LRNG is designed such that none of these noise sources can dominate the other noise sources to provide seed data to the TRNG during boot time due to the following:

(a) During boot time, the amount of received interrupts are the trigger points to (re)seed the TRNG.

(b) At runtime, the caller requesting random numbers from the primary TRNG drives the reseeding where always as much entropy as available is used to reseed the TRNG.

4. The entropy pool accumulates entropy obtained from certain events, which will henceforth be collectively called "slow noise sources". The entropy pool collects noise data from slow noise sources. Any data received by the LRNG from the slow noise sources is inserted into the entropy pool using an LFSR with a primitive and irreducible polynomial. The following sources of entropy are used:

(a) When an interrupt occurs, the high-resolution time stamp is mixed
into the LFSR. This time stamp is credited with heuristically implied entropy.

(b) HID event data like the key stroke or the mouse coordinates are
mixed into the LFSR. This data is not credited with entropy by the LRNG.

(c) Device drivers may provide data that is mixed into the LFSR. This
data is not credited with entropy by the LRNG.

(d) After the entropy pool is ``read'' by the TRNG, the data
used to seed the TRNG is mixed back into the entropy pool to stir the pool. This data is not credited with entropy by the LRNG.

Any data provided from user space by either writing to /dev/random, /dev/urandom or the IOCTL of RNDADDENTROPY on both device files are always injected into the entropy pool.

In addition, when a hardware random number generator covered by the Linux kernel HW generator framework wants to deliver random numbers, it is injected into the entropy pool as well. HW generator noise source is handled separately from the other noise source due to the fact that the HW generator framework may decide by itself when to deliver data whereas the other noise sources always requested for data driven by the LRNG operation. Similarly any user space provided data is inserted into the entropy pool.

When the TRNG requires data from the entropy pool, the entire entropy pool is processed with an SP800-90A section 10.3.1 compliant hash_df function to generate random numbers.

To speed up the interrupt handling code of the LRNG, the time stamp collected for an interrupt event is truncated to the 8 least significant bits. 64 truncated time stamps are concatenated and then jointly inserted into the LFSR. During boot time, until the fully seeded stage is reached, each time stamp with its 32 least significant bits is inserted into the LFSR at the time of arrival.

The LRNG allows the TRNG and secondary DRNG mechanism to be changed at runtime. Per default, a ChaCha20-based DRNG is used. The ChaCha20-DRNG implemented for the LRNG is also provided as a stand-alone user space deterministic random number generator. The LRNG also offers an SP800-90A DRBG based on the Linux kernel crypto API DRBG implementation.

The DRNG allows two methods of obtaining random data:

* For users requiring random numbers from a seeded and frequently reseeded secondary DRNG, such as the /dev/urandom, the getrandom system call or the in-kernel get_random_bytes function, the secondary DRNG is accessed directly by invoking its generate function. This generate function complies with the generate function discussed in SP800-90A.

* Users requiring random data that contains information theoretical entropy, such as for seeding other DRNGs also use the TRNG's generate function via the /dev/random device file and the getrandom system call when invoked with GRND_RANDOM. The difference to the /dev/urandom handling is that:

1. each TRNG generate request is limited to the amount of entropy
the of the DRNG was seeded with, and

2. each TRNG generate request is preceded by a reseeding of the
DRNG to implement a TRNG / a DRNG with prediction resistance.

The processing of entropic data from the noise source before injecting them into the TRNG is performed with the following mathematical operations:

1. LFSR: The 8 least significant bits of the time stamp data received from the interrupts are processed with an LFSR. That LFSR is implemented identically to the LSFR used in the existing /dev/random implementation except that it is capable of processing an entire word and that a different polynomial is used. The reason for the different polynomial is performance in a performance sensitive code section, the interrupt handler. The chosen polynomials have 4 taps. Also, this LFSR-approach is used in the OpenBSD /dev/random equivalent.

2. Concatenation: The temporary seed buffer used to seed the TRNG is a concatenation of parts of the entropy pool data, and the CPU noise source output.

The TRNG always tries to seed itself with 256 bits of entropy, except during boot. In any case, if the noise sources cannot deliver that amount, the available entropy is used and the TRNG keeps track on how much entropy it was seeded with. The entropy implied by the LRNG available in the entropy pool may be too conservative. To ensure that during boot time all available entropy from the entropy pool is transferred to the TRNG, the hash_df function always generates 256 data bits during boot to seed the TRNG. Yet, the TRNG entropy estimate is only increased by the amount of entropy the LRNG assumes to be present in that data. During boot, the TRNG is seeded as follows:

1. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if the entropy pool has collected at least 32 bits of entropy from the interrupt noise source. The goal of this step is to ensure that the primary and secondary DRNG receive some initial entropy as early as possible. In addition it receives the entropy available from the fast noise sources.

2. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if all noise sources collectively can provide at least 128 bits of entropy.

3. The DRNG is reseeded from the entropy pool and potentially the fast noise sources if all noise sources collectivel can provide at least 256 bits.

At the time of the reseeding steps, the DRNG requests as much entropy as is available in order to skip certain steps and reach the seeding level of 256 bits. This may imply that one or more of the aforementioned steps are skipped.

In all listed steps, the secondary DRNG is (re)seeded with a number of random bytes from the TRNG that is equal to the amount of entropy the TRNG was seeded with. This means that when the TRNG is seeded with 128 or 256 bits of entropy, the secondary DRNG is seeded with that amount of entropy as well. There is only one exception to that rule: during initialization before the seed level of 128 bits is reached, a random number with 128 bit is generated by the TRNG to seed the secondary DRNG.

Before the TRNG is seeded with 256 bits of entropy in step 3, requests of random data from /dev/random are not processed.

At runtime, the TRNG delivers only random bytes equal to the entropy amount it was seeded with. E.g. if the TRNG was seeded with 128 bits of entropy, it will return only 128 bits of random data. Subsequent requests for random data are only fulfilled after a reseeding operation of the TRNG.

The TRNG will always require that all entropy sources collectively can deliver at least as many entropy bits as configured with /proc/sys/kernel/random/read_wakeup_threshold, i.e. per default 129 bits (128 bits of entropy for seeding plus one bit of entropy that is lost with the post processing as defined in SP800-90B).

The secondary DRNG operates as deterministic random number generator with the following properties:

* The maximum number of random bytes that can be generated with one DRNG generate operation is limited to 4096 bytes. When longer random numbers are requested, multiple DRNG generate operations are performed. The ChaCha20 DRNG as well as the SP800-90A DRBGs implement an update of their state after completing a generate request for backtracking resistance.

* The secondary DRNG is reseeded with whatever entropy is available – in the worst case where no additional entropy can be provided by the noise sources, the DRNG is not re-seeded and continues its operation to try to reseed again after again the expiry of one of these thresholds:

- If the last reseeding of the secondary DRNG is more than 600 seconds ago, or

- 2^20 DRNG generate operations are performed, whatever comes first, or

- the secondary DRNG is forced to reseed before the next generation of random numbers if data has been injected into the LRNG by writing data into /dev/random or /dev/urandom.

The chosen values prevent high-volume requests from user space to cause frequent reseeding operations which drag down the performance of the DRNG.

When the secondary DRNG requests a reseeding from the TRNG and the TRNG pulls from the entropy pool, an emergency entropy level of 512 bits of entropy is left in the entropy pool. This emergency entropy is provided to serve /dev/random even while /dev/urandom is stressed.

With the automatic reseeding after 600 seconds, the LRNG is triggered to reseed itself before the first request after a suspend that put the hardware to sleep for longer than 600 seconds.

The TRNG may not be compiled. In this case, the aforementioned statements covering the TRNG are not applicable. The secondary DRNG is seeded directly from the entropy pool just like the TRNG would have been seeded.

The LRNG has the following properties:

* internal noise source: interrupts timing with fast boot time seeding

* high performance of interrupt handling code: The LRNG impact on the interrupt handling has been reduced to a minimum. On one example system, the LRNG interrupt handling code executes within an average of 65 cycles whereas the existing /dev/random on the same device takes about 97 cycles when measuring the execution time of add_interrupt_randomness().

* lockless LFSR to collect raw entropy

* use of standalone ChaCha20 based RNG with the option to use a different DRNG selectable at compile time

* "atomic" seeding of secondary DRBG to ensure full entropy transport

* instantiate one DRNG per NUMA node

* support for runtime switchable output DRNGs

* support for TRNG deactivation: The LRNG supports the compile-time deactivation of the TRNG (i.e. the blocking behavior of /dev/random). If deactivated, /dev/random operates like getrandom(2). This is intended to cover the recent discussions about removing the blocking_pool from the existing random.c.

* use of only well-defined entropy-preserving operations to collect, compress and forward entropy: concatenation, LFSR, SP800-90A hash_df function

* compile-time selectable entropy pool size: the choice also uses the applicable LFSR polynomial to maintain the entropy pool size

Further details including the rationale for the design choices and properties of the LRNG together with testing is provided at [1]. In addition, the documentation explains the conducted regression tests to verify that the LRNG is API and ABI compatible with the existing /dev/random implementation.

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

CC: "Eric W. Biederman" <[email protected]>
CC: "Alexander E. Patrakov" <[email protected]>
CC: "Ahmed S. Darwish" <[email protected]>
CC: "Theodore Y. Ts'o" <[email protected]>
CC: Willy Tarreau <[email protected]>
CC: Matthew Garrett <[email protected]>
CC: Vito Caputo <[email protected]>
CC: Andreas Dilger <[email protected]>
CC: Jan Kara <[email protected]>
CC: Ray Strode <[email protected]>
CC: William Jon McCann <[email protected]>
CC: zhangjs <[email protected]>
CC: Andy Lutomirski <[email protected]>
CC: Florian Weimer <[email protected]>
CC: Lennart Poettering <[email protected]>
CC: Nicolai Stange <[email protected]>
Mathematical aspects Reviewed-by: "Peter, Matthias" <[email protected]>

---
 MAINTAINERS                         |   7 +
 drivers/char/Kconfig                |   2 +
 drivers/char/Makefile               |   9 +-
 drivers/char/lrng/Kconfig           |  55 +++
 drivers/char/lrng/Makefile          |   9 +
 drivers/char/lrng/lrng_archrandom.c |  92 ++++
 drivers/char/lrng/lrng_aux.c        | 148 +++++++
 drivers/char/lrng/lrng_chacha20.c   | 328 ++++++++++++++
 drivers/char/lrng/lrng_interfaces.c | 648 +++++++++++++++++++++++++++
 drivers/char/lrng/lrng_internal.h   | 300 +++++++++++++
 drivers/char/lrng/lrng_pool.c       | 660 ++++++++++++++++++++++++++++
 drivers/char/lrng/lrng_sdrng.c      | 436 ++++++++++++++++++
 drivers/char/lrng/lrng_sw_noise.c   | 144 ++++++
 include/linux/lrng.h                |  83 ++++
 14 files changed, 2920 insertions(+), 1 deletion(-)
 create mode 100644 drivers/char/lrng/Kconfig
 create mode 100644 drivers/char/lrng/Makefile
 create mode 100644 drivers/char/lrng/lrng_archrandom.c
 create mode 100644 drivers/char/lrng/lrng_aux.c
 create mode 100644 drivers/char/lrng/lrng_chacha20.c
 create mode 100644 drivers/char/lrng/lrng_interfaces.c
 create mode 100644 drivers/char/lrng/lrng_internal.h
 create mode 100644 drivers/char/lrng/lrng_pool.c
 create mode 100644 drivers/char/lrng/lrng_sdrng.c
 create mode 100644 drivers/char/lrng/lrng_sw_noise.c
 create mode 100644 include/linux/lrng.h

index cba1095547fd..7232989d3a1c 100644
@@ -9488,6 +9488,13 @@ F:	Documentation/core-api/atomic_ops.rst
 F:	Documentation/core-api/refcount-vs-atomic.rst
 F:	Documentation/memory-barriers.txt
 
+LINUX RANDOM NUMBER GENERATOR (LRNG) DRIVER
+M:	Stephan Mueller <[email protected]>
+S:	Maintained
+W:	https://www.chronox.de/lrng.html
+F:	drivers/char/lrng/*
+F:	include/linux/lrng.h
+
 LIS3LV02D ACCELEROMETER DRIVER
 M:	Eric Piel <[email protected]>
 S:	Maintained

index df0fc997dc3e..cebb3a62c2ca 100644
@@ -535,6 +535,8 @@ config ADI
 	  and SSM (Silicon Secured Memory).  Intended consumers of this
 	  driver include crash and makedumpfile.
 
+source "drivers/char/lrng/Kconfig"
+
 endmenu
 
 config RANDOM_TRUST_CPU

index 7c5ea6f9df14..46ede09fd6d3 100644
@@ -3,7 +3,14 @@
 # Makefile for the kernel character device drivers.
 #
 
-obj-y				+= mem.o random.o
+obj-y				+= mem.o
+
+ifeq ($(CONFIG_LRNG),y)
+  obj-y				+= lrng/
+else
+  obj-y				+= random.o
+endif
+
 obj-$(CONFIG_TTY_PRINTK)	+= ttyprintk.o
 obj-y				+= misc.o
 obj-$(CONFIG_ATARI_DSP56K)	+= dsp56k.o

new file mode 100644
index 000000000000..2761623715d2
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the Linux Random Number Generator.
+#
+
+obj-y				+= lrng_pool.o lrng_aux.o \
+				   lrng_sw_noise.o lrng_archrandom.o \
+				   lrng_sdrng.o lrng_chacha20.o \
+				   lrng_interfaces.o \

2.23.0

Am Samstag, 16. November 2019, 12:25:21 CET schrieb Thomas Gleixner:

Hi Thomas,

The main code path is lrng_time_process(). This code is streamlined as you already suggested: it is very lightweight to the interrupt handler. Compared to the existing /dev/random implementation it is about 50% faster.

When measuring the lrng_time_process, it takes on one particular test system on average about 65 cycles where on that very same system the add_interrupt_randomness code path from the existing /dev/random takes on average about 97 cycles.

The additional code you see in the add_interrupt_randomness is only executed if lrng_pool_highres_timer is not set. This is not set if the LRNG does not find a high-resolution time stamp, i.e. random_get_entropy() returns 0. As on most architectures this is now set, this code path is not executed.

This additional code path serves as an emergency code to collect some data that smells random and having entropy but not having really much.

It may be a bit more stremlined but since it is hardly used, I left it as it is so far. Do you see the need to streamline it more at this time?

Thanks a lot.

Ciao
Stephan

Hi Stephan,

I think that this can get called a bit too early through the get_random_bytes() invoked from e.g. boot_init_stack_canary(): in start_kernel(), there is

	boot_init_stack_canary();

	time_init();

On ARM (at least with arm_arch_timer.c), get_cycles() would return 0 until

time_init() => timer_probe() => arch_timer_of_init() => arch_timer_common_init() => arch_timer_arch_init() => arch_timer_delay_timer_register() => register_current_timer_delay()

has executed and thus, ...

[    0.000000] lrng_sdrng: operating without high-resolution timer and applying IRQ oversampling factor 10
[    0.000000] lrng_chacha20: ChaCha20 core initialized
[    0.000000] lrng_chacha20: ChaCha20 core initialized
[    0.000014] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 2147483647500ns
[    0.000036] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275 ns
[    0.000114] bcm2835: system timer (irq = 27)
[    0.000594] arch_timer: cp15 timer(s) running at 19.20MHz (phys).
[    0.000613] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[    0.000631] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[    0.000645] Switching to timer-based delay loop, resolution 52ns

SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Felix Imendörffer

Am Samstag, 16. November 2019, 19:13:23 CET schrieb Nicolai Stange:

Hi Nicolai,