Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3808029pxu; Tue, 20 Oct 2020 00:33:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyLBt2tdyqQsrtAcVYE63i2EqZTadxi9h7/EQR/szDDoq6Of14l+eYqTnWaVCNhXrwO3iqx X-Received: by 2002:a50:aa84:: with SMTP id q4mr1408859edc.331.1603179220419; Tue, 20 Oct 2020 00:33:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603179220; cv=none; d=google.com; s=arc-20160816; b=tBKaGjhw/+zi94gx8nLGdwxpJr9g6DOxeoBI8G375McX5+OE7VJHpfj4HF76CTbrVV Ov8WMS5UZy7wdNUw5zn4IZQ0Xlf74OELz7vxteICqoDiygwJr+HaieIqzr/Z27M884PX DLh4LLSQ4DTQqLGn4ljc/7NgLR58c20ryP+Co7slkrkOtZBMi1fwBvSpItzxYH1t8DEK ahr5x511tB5ax63tdBH4kz/UIx20GjGbSveCHrQWWTmZVBcqGcpA7ba6KvNWGEfcxExl BWWYxCB7xC7gjL/rVS1nxc1+63bbU7XOA3G2nZJXSERt/AGt+1DQRfKM7tnx0d3eIL7B Di0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=N/M+NbUCu03yHFK1fy2Lz+qA6c95Z2sAxVpSY2C7mgY=; b=0ZLPW2Ls+oQxnVzQ6AismBiinjkvdEAB6SWzj6DKEU7C50EpJZoctLzrcTfYFdfNn4 JdW6c/aUjhbIKspfFe+w5IsIWoNZrXYUChAvULsZ7vYucJ5+u21Oz3qgquPwBrmbcbQC hRHokaVyJvJR16/eMF01Rn4PN7esdUVarqYV9eiECnKkB3EvfLleQpWBgfhXBvA6kR7q MTBdtTZ/mmZwgjQN/d8sNnQT7Z1RnqVhwicqFjhpY+hgswY+q6QuDqgRjdpMA1VP1GeM q8P9co4n5SpsgPCBH90hHwfMvE1bFSIe9H3RP7DCo1+Gte+awkXMivRZDdmjLqCReanM wZfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chronox.de header.s=strato-dkim-0002 header.b=KfPv6qhr; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gf16si706650ejb.694.2020.10.20.00.33.17; Tue, 20 Oct 2020 00:33:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chronox.de header.s=strato-dkim-0002 header.b=KfPv6qhr; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731551AbgJSTxG (ORCPT + 99 others); Mon, 19 Oct 2020 15:53:06 -0400 Received: from mo4-p04-ob.smtp.rzone.de ([81.169.146.176]:28229 "EHLO mo4-p04-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731523AbgJSTxF (ORCPT ); Mon, 19 Oct 2020 15:53:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603137179; s=strato-dkim-0002; d=chronox.de; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=N/M+NbUCu03yHFK1fy2Lz+qA6c95Z2sAxVpSY2C7mgY=; b=KfPv6qhrJGX1FBdtr0wuUJLXifCguRkCfEw3Z9LjnkKblF6md+iSBVq34rdoiGWUzI 3WVxYyk8u47HE6E4d8DyxEJEdPIxXyj1V28mOen6o1+HRDg8/eCXF7Iim4aiwEVxgEvT UMisHD+o9e1joKW248N4YBdTIDlyu514Ua1fnl3Kz8wrD73zPN8yCntd9EB2HH4q7mUR LIKuS7rG01rcjzX+S6Vgc6hZhuim4Kdk79+gczJeuGunre7iC4Sug7f+qjEdq4w4uSCo FEw332QiNCcwww51VjYryS/t0pmp+Jlhs05G4YhyR30A+VUOCAevxIMRSAbBRl4sTObZ xFEg== X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzGHXPbJPSb3t0=" X-RZG-CLASS-ID: mo00 Received: from positron.chronox.de by smtp.strato.de (RZmta 47.2.1 DYNA|AUTH) with ESMTPSA id C0b627w9JJpxU70 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 19 Oct 2020 21:51:59 +0200 (CEST) From: Stephan =?ISO-8859-1?Q?M=FCller?= To: Torsten Duwe Cc: Willy Tarreau , "Theodore Y. Ts'o" , linux-crypto@vger.kernel.org, Nicolai Stange , LKML , Arnd Bergmann , Greg Kroah-Hartman , "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Peter Matthias , Marcelo Henrique Cerri , Neil Horman , Randy Dunlap , Julia Lawall , Dan Carpenter , Andy Lavr , Eric Biggers , "Jason A. Donenfeld" , Petr Tesarik Subject: [PATCH v36 00/13] /dev/random - a new approach Date: Mon, 19 Oct 2020 21:28:50 +0200 Message-ID: <3073852.aeNJFYEL58@positron.chronox.de> In-Reply-To: <20201016172619.GA18410@lst.de> References: <20200921075857.4424-1-nstange@suse.de> <2961243.vtBmWVcJkq@tauon.chronox.de> <20201016172619.GA18410@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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. It provides the same API and ABI and can be used as a drop-in replacement. The LRNG implements at least all features of the existing /dev/random such = as NUMA-node-local DRNGs. Patches 1 through 3 provide the code that is feature- identical. The following advantages compared to the existing /dev/random implementation are present: * Sole use of crypto for data processing: - Exclusive use of a hash operation for conditioning entropy data with a clear mathematical description as given in [2] section 2.2 - non-cryptographic operations like LFSR are not used. - The LRNG uses only properly defined and implemented cryptographic algorithms unlike the use of the SHA-1 transformation in the existing /dev/random implementation. - Hash operations use NUMA-node-local hash instances to benefit large parallel systems. - LRNG uses limited number of data post-processing steps as documented in [2] section 2.2 compared to the large variation of different post-processing steps in the existing /dev/random implementation that have no apparent mathematical description (see [2] section 4.5). * Performance - Faster by up to 75% in the critical code path of the interrupt handler depending on data collection size configurable at kernel compile time - the default is about equal in performance with existing /dev/random as outlined in [2] section 4.2. - Configurable data collection sizes to accommodate small environments and big environments via CONFIG_LRNG_COLLECTION_SIZE. - Entropy collection using an almost never contended lock to benefit large parallel systems =E2=80=93 worst case rate of contention is the nu= mber of DRNG reseeds, usually the number of potential contentions per 10 minutes is equal to number of NUMA nodes. - ChaCha20 DRNG is significantly faster as implemented in the existing /dev/random as demonstrated with [2] table 2. - Faster entropy collection during boot time to reach fully seeded level, including on virtual systems or systems with SSDs as outlined in [2] section 4.1. * Testing - Availablility of run-time health tests of the raw unconditioned noise source to identify degradation of the available entropy as documented in [2] section 2.5.4. Such health tests are important today due to virtual machine monitors reducing the resolution of or disabling the high-resolution timer. - Heuristic entropy estimation is based on quantitative measurements and analysis following SP800-90B and not on coincidental underestimation of entropy applied by the existing /dev/random as outlined in [4] section 4.4. - Power-on self tests for critical deterministic components (ChaCha20 DRNG, software hash implementation, and entropy collection logic) not already covered by power-up tests of the kernel crypto API as documented in [2] section 2.14. - Availability of test interfaces for all operational stages of the LRNG including boot-time raw entropy event data sampling as outlined in [2] section 2.15. - Fully testable ChaCha20 DRNG via a userspace ChaCha20 DRNG implementation [3]. - In case of using the kernel crypto API SHASH hash implementation, it is fully testable and tested via the NIST ACVP test framework, for example certificates A734, A737, and A738. - The LRNG offers a test interface to validate the used software hash implementation and in particular that the LRNG invokes the hash correctly, allowing a NIST ACVP-compliant test cycle - see [2] section 2.15. - Availability of stress testing covering the different code paths for data and mechanism (de)allocations and code paths covered with locks. * Entropy collection - The LRNG is shipped with test tools allowing the collection of raw unconditioned entropy during runtime and boot time available at [1]. - Full entropy assessment and description is provided with [2] chapter 3, specifically section 3.2.6. - Guarantee that entropy events are not credited with entropy twice (the existing /dev/random implementation credits HID/disk and interrupt events with entropy which are a derivative of each other) and guarantee that entropy data is not reused for two different use cases (as done in the existing /dev/random implementation when injecting a part of fast_pool into the net_rand_state). * Configurable - LRNG kernel configuration allows configuration that is functionally equivalent to the existing /dev/random. Non-compiled additional code is folded into no-ops. - The following additional functions are compile-time selectable independent of each other: + Enabling of switchable cryptographic implementation support. This allows enabling an SP800-90A DRBG. + Enabling of using Jitter RNG noise source. + Enabling of noise source health tests. + Enabling of test interface allowing to enable each test interface individually. + Enabling of the power-up self test. - At boot-time, the SP800-90B health tests can be enabled as outlined in [2] section 2.5.4. - At boot-time, the entropy rate used to credit the external CPU-based noise source and Jitter RNG noise source can be configured including setting an entropy rate of zero or full entropy - see [2] sections 2.5.2 and 2.5.3. * Run-time pluggable cryptographic implementations used for all data processing steps specified in [2] section 2.2 - The DRNG can be replaced with a different implementation allowing any type of DRNG to provide data via the output interfaces. The LRNG provides the following types of DRNG implementations: + ChaCha20-based software implementation that is used per default. + SP800-90A DRBG using accelerated cryptographic implementations that may sleep. + Any DRNG that is accessible via the kernel crypto API RNG subsystem. - The hash component can be replaced with any other hash implementation provided the implementation does not sleep. The LRNG provides the access to the following types of non-sleeping hash implementations: + SHA-256 software implementation that is used per default. Due to kernel build system inconsistencies, the software SHA-1 implementation is used if the kernel crypto API is not compiled. + SHA-512 hash using the fastest hash implementation available via the kernel crypto API SHASH subsystem. * Code structure - The LRNG source code is available for current upstream Linux kernel separate to the existing /dev/random which means that users who are conservative can use the unchanged existing /dev/random implementation. - Back-port patches are available at [5] to apply the LRNG to Linux kernel versions of 5.8, 5.4, 4.19, 4.14, 4.12, and 4.10. Patches for other kernel versions are easily derived from the existing ones. Booting the patch with the kernel command line option "dyndbg=3Dfile drivers/char/lrng/* +p" generates logs indicating the operation of the LRNG. Each log is pre-pended with "lrng". An entropy analysis is performed on the following systems - details are given in [2] appendix C: * x86 KVM virtualized guest 32 and 64 bit systems * x86 bare metal * older and newer ARMv7 system * ARM64 * POWER7 LE and POWER 8 BE * IBM Z System mainframe * old MIPS embedded device * testing with GCC and Clang [1] https://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. [2] https://www.chronox.de/lrng/doc/lrng.pdf [3] https://www.chronox.de/chacha20_drng.html [4] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studie= s/LinuxRNG/LinuxRNG_EN_V4_1.pdf [5] https://github.com/smuellerDD/lrng/tree/master/backports Changes (compared to the previous patch set) - individual patches are visible at https://github.com/smuellerDD/lrng/commits/master: * fix display of available entropy - the fix only affects the display of available entropy at /proc/sys/kernel/random/entropy_avail * simplify code to obtain available and max entropy * always reset entropy gathering interface when listener detaches CC: Torsten Duwe CC: "Eric W. Biederman" CC: "Alexander E. Patrakov" CC: "Ahmed S. Darwish" CC: "Theodore Y. Ts'o" CC: Willy Tarreau CC: Matthew Garrett CC: Vito Caputo CC: Andreas Dilger CC: Jan Kara CC: Ray Strode CC: William Jon McCann CC: zhangjs CC: Andy Lutomirski CC: Florian Weimer CC: Lennart Poettering CC: Nicolai Stange CC: Eric Biggers Tested-by: Roman Drahtm=C3=BCller Tested-by: Marcelo Henrique Cerri Stephan Mueller (13): Linux Random Number Generator LRNG - allocate one DRNG instance per NUMA node LRNG - sysctls and /proc interface LRNG - add switchable DRNG support LRNG - add common generic hash 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 SP800-90B compliant health tests LRNG - add interface for gathering of raw entropy LRNG - add power-on and runtime self-tests MAINTAINERS | 7 + crypto/drbg.c | 16 +- crypto/jitterentropy-kcapi.c | 3 +- crypto/jitterentropy.c | 31 +- drivers/char/Kconfig | 2 + drivers/char/Makefile | 9 +- drivers/char/lrng/Kconfig | 353 +++++++++ drivers/char/lrng/Makefile | 20 + drivers/char/lrng/lrng_archrandom.c | 93 +++ drivers/char/lrng/lrng_aux.c | 136 ++++ drivers/char/lrng/lrng_chacha20.c | 352 +++++++++ drivers/char/lrng/lrng_chacha20.h | 29 + drivers/char/lrng/lrng_drbg.c | 197 +++++ drivers/char/lrng/lrng_drng.c | 406 +++++++++++ drivers/char/lrng/lrng_health.c | 407 +++++++++++ drivers/char/lrng/lrng_interfaces.c | 649 +++++++++++++++++ drivers/char/lrng/lrng_internal.h | 429 +++++++++++ drivers/char/lrng/lrng_jent.c | 88 +++ drivers/char/lrng/lrng_kcapi.c | 228 ++++++ drivers/char/lrng/lrng_kcapi_hash.c | 97 +++ drivers/char/lrng/lrng_kcapi_hash.h | 19 + drivers/char/lrng/lrng_numa.c | 108 +++ drivers/char/lrng/lrng_pool.c | 457 ++++++++++++ drivers/char/lrng/lrng_proc.c | 182 +++++ drivers/char/lrng/lrng_selftest.c | 344 +++++++++ drivers/char/lrng/lrng_sw_noise.c | 466 ++++++++++++ drivers/char/lrng/lrng_sw_noise.h | 56 ++ drivers/char/lrng/lrng_switch.c | 203 ++++++ drivers/char/lrng/lrng_testing.c | 689 ++++++++++++++++++ include/crypto/drbg.h | 7 + .../crypto/internal}/jitterentropy.h | 3 + include/linux/lrng.h | 79 ++ 32 files changed, 6155 insertions(+), 10 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_chacha20.h create mode 100644 drivers/char/lrng/lrng_drbg.c create mode 100644 drivers/char/lrng/lrng_drng.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_kcapi_hash.c create mode 100644 drivers/char/lrng/lrng_kcapi_hash.h 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_selftest.c create mode 100644 drivers/char/lrng/lrng_sw_noise.c create mode 100644 drivers/char/lrng/lrng_sw_noise.h create mode 100644 drivers/char/lrng/lrng_switch.c create mode 100644 drivers/char/lrng/lrng_testing.c rename {crypto =3D> include/crypto/internal}/jitterentropy.h (84%) create mode 100644 include/linux/lrng.h =2D-=20 2.26.2