From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA52BC43331 for ; Tue, 12 Nov 2019 15:34:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC28021E6F for ; Tue, 12 Nov 2019 15:34:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573572854; bh=DXYIyanra3jNg47NQU0uVZtkQQqgQMq2XaV52IXf3Og=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=lzzChSjY22PQr0vQaTRedSNDpNHVYF+eHWzNBS9fXBwAgQHvYP/2Xup2NHRqAdXox 3ZsMCBsvfBODa/1sWSpwMEn6uJUnQX02HH4VhwUxKSCB1gMCAtvI7EPeWWjxOv3Hg7 oBmEA9FlEIJx3g+W8+Fj0sNDGLv9G5eEtQ33M3tI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727129AbfKLPeO (ORCPT ); Tue, 12 Nov 2019 10:34:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:43064 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725954AbfKLPeN (ORCPT ); Tue, 12 Nov 2019 10:34:13 -0500 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 58993214E0 for ; Tue, 12 Nov 2019 15:34:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573572852; bh=DXYIyanra3jNg47NQU0uVZtkQQqgQMq2XaV52IXf3Og=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=BaEKCGQLPe+KFtrP/ScOjosruT1d1FXj5QHeMMrbSLUK2fYnTuWbNLNCCzVbLBeH4 zo0gME3w00O1xW0xJdxWBThGw2L/siUTUSDBjFUGr7M2CQUrhKT89+BSM4fvL0n1uZ CK6WhP44e9J5L25Xq0ENqFp+KACu9/7qg1XRL1xk= Received: by mail-wm1-f52.google.com with SMTP id z19so3426647wmk.3 for ; Tue, 12 Nov 2019 07:34:12 -0800 (PST) X-Gm-Message-State: APjAAAV/tlgVvsTChaE9Mt5i4nh6PZBhWw/nXZUwOWd+wCPJlyyzBR+i k/9II/cnYzBRETzYQL+jM635PP21fFo0jblHkYwn8g== X-Google-Smtp-Source: APXvYqxTDJMLUPvzsq/nAiAh1IFJuOAwbzKC6VPlu6JcodO6aU5gAbxzpC395iIuoKGovo5d72M8gyJmjOUVwXR/UfA= X-Received: by 2002:a05:600c:1002:: with SMTP id c2mr4486257wmc.79.1573572850848; Tue, 12 Nov 2019 07:34:10 -0800 (PST) MIME-Version: 1.0 References: <6157374.ptSnyUpaCn@positron.chronox.de> In-Reply-To: <6157374.ptSnyUpaCn@positron.chronox.de> From: Andy Lutomirski Date: Tue, 12 Nov 2019 07:33:59 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v24 00/12] /dev/random - a new approach with full SP800-90B compliance To: =?UTF-8?Q?Stephan_M=C3=BCller?= Cc: Arnd Bergmann , Greg Kroah-Hartman , Linux Crypto Mailing List , LKML , Linux API , "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 11, 2019 at 11:13 AM Stephan M=C3=BCller = wrote: > > The following patch set provides a different approach to /dev/random whic= h 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 an= d 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. This is very nice! > > The LRNG patch set allows a user to select use of the existing /dev/rando= m or > the LRNG during compile time. As the LRNG provides API and ABI compatible > interfaces to the existing /dev/random implementation, the user can freel= y 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. 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=3Dran= dom/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