Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3754613ybe; Mon, 16 Sep 2019 00:09:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqxRn88F174lGYbgmNHFpphBrCPNk3L07gVAhQ98i6KPufULsY12GaUdGqZmN37c6GkraLJ/ X-Received: by 2002:a17:906:d050:: with SMTP id bo16mr41547950ejb.146.1568617747660; Mon, 16 Sep 2019 00:09:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568617747; cv=none; d=google.com; s=arc-20160816; b=TEy1GEU3q7PdcchOm+rtOqkWZ70FdbC+myu/9COqh02bKxw6iTSBGvhX4KMzOVrh45 EuBN7f7gObqLe0U0WEO6WKYz7wbnMqLC45oADiiDFHF2HqptHw+hqgP2sukNa02M8lTp Rp85XCFnCayI2j7IuSC13eAQvRflumaJbQ1757YbIxDxwTTBYOtu+d+WFYmYGmIQvvE0 IdZge0Oe5rJWjBVMfgmhiONzgk4+6LXrWu8HZJKbC/o6Rq6eAE/GnSpOXYC2XpY8ntJ1 Qbt3v01+Y5WFE9VnaMutbHLP28h1A7oXBb9BBHezKX8z+iRk9xulqsxVHTxjzk8N1ayV jiNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ATjzMPiaxZhJtWKkpa6ZZRDjqdNJhfDuTt17kZl4oDE=; b=o4/sc65F/rxlXQYnsCEhC96karIk2fOktvPviDCwB3OZyVPyX9boA6WmeBNcI7YySv qSqBR11yzkPpwe/r1KDNOpydOIp4oMiVtSMR5kQNPxWpYk6txqIrEyEwvSSrBvGhPGfu 0u0qdjRgxFojEA9NGqjyHrgrTnxV35msspjVuEIwkS3LBkws9beR6xXDMS72JlGM0iv2 mBr/I0KN3rVU+7VEJW2zbyD9lDwSa023biDOeCHVhYYS7OY4VT0n93D7+gLnXZifYWP+ 7CFAZRsFU7s1m4gS3ear815hD9vxTFO7FeXendEHBgogkT/1k/PHW52+SOCZW9LaHmca otvw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id nm3si18943045ejb.310.2019.09.16.00.08.43; Mon, 16 Sep 2019 00:09:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726283AbfIPEaU (ORCPT + 99 others); Mon, 16 Sep 2019 00:30:20 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:45652 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725985AbfIPEaU (ORCPT ); Mon, 16 Sep 2019 00:30:20 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8G4Tqla023841; Mon, 16 Sep 2019 06:29:52 +0200 Date: Mon, 16 Sep 2019 06:29:52 +0200 From: Willy Tarreau To: "Theodore Y. Ts'o" Cc: Vito Caputo , "Ahmed S. Darwish" , Linus Torvalds , Lennart Poettering , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190916042952.GB23719@1wt.eu> References: <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <20190915065142.GA29681@gardel-login> <20190916014050.GA7002@darwi-home-pc> <20190916014833.cbetw4sqm3lq4x6m@shells.gnugeneration.com> <20190916024904.GA22035@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190916024904.GA22035@mit.edu> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hi Ted, On Sun, Sep 15, 2019 at 10:49:04PM -0400, Theodore Y. Ts'o wrote: > No matter *what* we do, it's going to either (a) make some > systems insecure, or (b) make some systems more likely hang while > booting. I continue to strongly disagree with opposing these two. (b) is caused precisely because of this conflation. Life long keys are produced around once per system's life (at least this order of magnitude). Boot happens way more often. Users would not complain that systems fail to start if the two types of random are properly distinguished so that we don't fail to boot just for the sake of secure randoms that will never be consumed as such. Before systems had HWRNGs it was pretty common for some tools to ask the user to type hundreds of characters on the keyboard and use that (content+timings) to feed entropy while generating a key. This is acceptable once in a system's life. And on some systems with no entropy like VMs, it's commonly generated from a central place and never from the VM itself, so it's not a problem either. In my opinion the problem recently happened because getrandom() was perceived as a good replacement for /dev/urandom and is way more convenient to use, so applications progressively started to use it without realizing that contrary to its ancestor it can block. And each time a system fails to boot confirms that entropy still remains a problem even on PCs in 2019. This is one more reason for clearly keeping two interfaces depending on what type of random is needed. I'd be in favor of adding in the man page something like "this random source is only suitable for applications which will not be harmed by getting a predictable value on output, and as such it is not suitable for generation of system keys or passwords, please use GRND_RANDOM for this". This distinction currently is not clear enough for people who don't know this subtle difference, and can increase the interface's misuse. Regards, Willy