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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 AB2BEC49ED7 for ; Mon, 16 Sep 2019 17:01:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 880AD2067D for ; Mon, 16 Sep 2019 17:01:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390183AbfIPRBO (ORCPT ); Mon, 16 Sep 2019 13:01:14 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:43672 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726082AbfIPRBO (ORCPT ); Mon, 16 Sep 2019 13:01:14 -0400 Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8GH0SBJ032514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 13:00:30 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id B581A420811; Mon, 16 Sep 2019 13:00:28 -0400 (EDT) Date: Mon, 16 Sep 2019 13:00:28 -0400 From: "Theodore Y. Ts'o" To: Linus Torvalds Cc: Lennart Poettering , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190916170028.GA15263@mit.edu> References: <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <214fed0e-6659-def9-b5f8-a9d7a8cb72af@gmail.com> <20190915065655.GB29681@gardel-login> <20190916032327.GB22035@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 15, 2019 at 08:40:30PM -0700, Linus Torvalds wrote: > On Sun, Sep 15, 2019 at 8:23 PM Theodore Y. Ts'o wrote: > > > > But not blocking is *precisely* what lead us to weak keys in network > > devices that were sold by the millions to users in their printers, > > wifi routers, etc. > > Ted, just admit that you are wrong on this, instead of writing the > above kind of bad fantasy. > > We have *always* supported blocking. It's called "/dev/random". And > guess what? Not blocking wasn't what lead to weak keys like you try to > imply. > > What led to weak keys is that /dev/random is useless and nobody sane > uses it, exactly because it always blocks. How /dev/random blocks is very different from how getrandom(2) blocks. Getrandom(2) blocks until the CRNG, and then it never blocks again. /dev/random tries to do entropy accounting, and it blocks randomly all the time. *That* is why it is useless. I agree that /dev/random is bad, but I think you're taking the wrong message from it. It's not that blocking is always bad; it's that insisting on entropy accounting and "true randomness" is bad. The getrandom(2) system call is modelled after *BSD's getentropy(2) call, and the fact that everyone is using is because for most use cases, it really is the right way to go. I think that's the core of my disagreement with you. I agree that what /dev/random does is wrong, and to date, we've kept it for backwards compatibility reasons. Some of these reasons could be rational, or at least debated. For example, GPG wants to use /dev/random because it thinks it's more secure, and if they are generating 4096 bit RSA keys, or something else which might be "post-quantuum cryptography", it's possible that /dev/random is going to be better than the CRNG for the hyper-paranoid. Other use cases, such as some PCI compliance labs who think that getrandom(2) is not sufficiently secure, are just purely insane --- but that's assuming today's getrandom(2) is guaranteed to return cryptographically strong results, or nothing at all. If we change the existing behavior of getrandom(2) with the default flags to mean, "we return whatever we feel like, and this includes something which looks random, but might be trivially reverse engineered by a research engineer", that is in my mind, a Really Bad Thing To Do. And no, a big fat warning isn't sufficient, because there will be some systems integrators and application programmers who will ignore the kernel warning message. They might not even look at dmesg, and a system console might not exist. - Ted