From patchwork Thu Jan 9 08:29:50 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Stephan Mueller X-Patchwork-Id: 11325215 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 07693109A for ; Thu, 9 Jan 2020 08:41:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C56632073A for ; Thu, 9 Jan 2020 08:41:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=chronox.de header.i=@chronox.de header.b="IiPiGmuq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728804AbgAIIlR (ORCPT ); Thu, 9 Jan 2020 03:41:17 -0500 Received: from mo4-p04-ob.smtp.rzone.de ([81.169.146.223]:21636 "EHLO mo4-p04-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728762AbgAIIlK (ORCPT ); Thu, 9 Jan 2020 03:41:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1578559266; 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=PYm8Gfs+nO0qPhM7QUoBsJ0iR80+RLCpJWdZzLY/ikM=; b=IiPiGmuqdkcZsXBvkhanH5NH2YF6OK8FN5Cl+z2BOtz0dzJuQDcgizxHZ/n+1E92Wk bvIoKtNoxvVE2Nert010oTKr+qc5g9F9Mju4gtU9cjYG0Grt6c2YgN8syY3QdQNPFfZD uC4/DoYKPVL147QXuOjRAixrFjao2SR6GY5kOjvPoaKxK2QD0KKP3SHhYUYiFwFHMUZB cK8WrngGDKcBS2EJLMGG64zBmPgG6jgFnBVRrBZm5r83cUZbsubI9py2W5m/WkAwOjU5 F2H7JUoKtBV6VAAT0HfwcMsQ+C43zGiF1pWjxSSXzo2gLBcchxMLwfsbyP/h/Y0ggPAi ILUg== X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzGHXPZJPScHivh" X-RZG-CLASS-ID: mo00 Received: from positron.chronox.de by smtp.strato.de (RZmta 46.1.4 DYNA|AUTH) with ESMTPSA id u04585w098cF2Zt (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Thu, 9 Jan 2020 09:38:15 +0100 (CET) From: Stephan =?iso-8859-1?q?M=FCller?= To: Arnd Bergmann Cc: Greg Kroah-Hartman , linux-crypto@vger.kernel.org, LKML , linux-api@vger.kernel.org, "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Willy Tarreau , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Nicolai Stange , "Peter, Matthias" , Marcelo Henrique Cerri , Roman Drahtmueller , Neil Horman , Randy Dunlap , Julia Lawall Subject: [PATCH v27 00/12] /dev/random - a new approach with full SP800-90B Date: Thu, 09 Jan 2020 09:29:50 +0100 Message-ID: <2641155.iNH938UiKq@positron.chronox.de> In-Reply-To: <2722222.P16TYeLAVu@positron.chronox.de> References: <6157374.ptSnyUpaCn@positron.chronox.de> <2787174.DQlWHN5GGo@positron.chronox.de> <2722222.P16TYeLAVu@positron.chronox.de> MIME-Version: 1.0 Sender: linux-crypto-owner@vger.kernel.org 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. 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 is 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. In addition, the LRNG is about 50% faster in the performance critical interrupt handler code path compared to the existing /dev/random implementation. [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): * fix function prototype of lrng_init_time_source * fix indentation in getrandom * add unlock to error code path as reported by Julia Lawall * integrate 0da522107e5d9c000a4871d52e570912aa1225a2 from Arnd Bergmann and supplemental patch 4aa37c463764052c68c5c430af2a67b5d784c1e0 from Jason A. Donenfeld * use new jitterentropy.h header file * add power-on self-tests of security critical functions of hash_df, LFSR, ChaCha20 DRNG, and time stamp array management * add support for significantly reduced runtime memory footprint as outlined in patch 1 * drop TRNG support - the LRNG has the same user experience as random.c with Andy Lutomirski's recent patch removing the blocking_pool - rename all *sdrng* symbols to *drng* * ensure that external noise sources can provide seed at least once when a DRNG is reseeded to ensure internal and external noise sources are balanced * add full documentation to all API calls provided to the remainder of the kernel * ensure that after a SP800-90B health test failure the interrupt handler triggers reseeds like during boot time This patch requires the presence of patch 75551dbf112c992bc6c99a972990b3f272247e23 from Ted Tso's kernel tree (specifically the addition of GRND_INSECURE to random.h) 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 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 Tested-by: Roman Drahtmüller Tested-by: Marcelo Henrique Cerri Stephan Mueller (12): Linux Random Number Generator LRNG - allocate one DRNG instance per NUMA node LRNG - sysctls and /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 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 | 25 +- drivers/char/Kconfig | 2 + drivers/char/Makefile | 9 +- drivers/char/lrng/Kconfig | 203 ++++++ 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 | 317 +++++++++ drivers/char/lrng/lrng_chacha20.h | 25 + drivers/char/lrng/lrng_drbg.c | 261 ++++++++ drivers/char/lrng/lrng_drng.c | 397 +++++++++++ drivers/char/lrng/lrng_health.c | 409 ++++++++++++ drivers/char/lrng/lrng_interfaces.c | 622 ++++++++++++++++++ drivers/char/lrng/lrng_internal.h | 305 +++++++++ drivers/char/lrng/lrng_jent.c | 87 +++ drivers/char/lrng/lrng_kcapi.c | 328 +++++++++ drivers/char/lrng/lrng_lfsr.h | 152 +++++ drivers/char/lrng/lrng_numa.c | 101 +++ drivers/char/lrng/lrng_pool.c | 585 ++++++++++++++++ drivers/char/lrng/lrng_proc.c | 163 +++++ drivers/char/lrng/lrng_selftest.c | 418 ++++++++++++ drivers/char/lrng/lrng_sw_noise.c | 102 +++ drivers/char/lrng/lrng_sw_noise.h | 57 ++ drivers/char/lrng/lrng_switch.c | 179 +++++ drivers/char/lrng/lrng_testing.c | 271 ++++++++ include/crypto/drbg.h | 7 + .../crypto/internal}/jitterentropy.h | 3 + include/linux/lrng.h | 71 ++ 31 files changed, 5374 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_lfsr.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 => include/crypto/internal}/jitterentropy.h (84%) create mode 100644 include/linux/lrng.h