Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2877518ybe; Sun, 15 Sep 2019 02:45:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqzKwjZwHxtyh/k+fs4KTDFQ/UA37tpwl6GP5D7dkOq+kDgZQIFTGoV8yeYUGdWUlBcFXwhU X-Received: by 2002:a50:dac2:: with SMTP id s2mr12218798edj.26.1568540709214; Sun, 15 Sep 2019 02:45:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568540709; cv=none; d=google.com; s=arc-20160816; b=RbPFtqlA1XvwwYfZtQUBnNZxKTlSPieKpVwNFpzoSJDp1EtmNzU1m95OzXV4nHRCgD vgCRqq0B9c7HyOJsVJOWcH3Iefx8t8xcu+2VLzsV//c3ZPO64zRPcNcfWoThwD/9oJdI +yHXjBARIyWAHneGotAN6Ukfu+epH4/auD+Rhkizl42A1gMGoRfJ8TPf/cIrdaAAh6/D Nhd78Qma9OqAGhJSB8BoyL/jXzRyiT77ZIyuzxMqAk+lnIPTSvG2nxZQ7Vd10v75jl+j q5hzvkLXJRNEH/d/Xj4W400sPcbhp9vSOIVVCUBleJFxuslwK+kBMwf3RM1awruzK5Ps z+Mg== 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=iS2eqIAaP7FSnH0u9Bbi6zl9prsP62C0un20elmGQYw=; b=PtrrrlP7QBdSGH0ru/ll2C9pB4GVvaWY/2KJoWiMkPhIGH/C3gADHHiKRvOC5iCb6s o2/OPPYTxjjxFyL3Ouq/Jv+sKHtA+TdqdxYkllQR/kYmBEGqpvzJZyVM1YJl/2JDceT1 oP/qlftngNcAV3i0UYP9NvdoCv8zptqJZoQDQYzCy8LvzNVrvokjCWxyuJWUFYBUmnPT 716Og/T0XqWhgcbsAXgMlka8nwWLHqTVX55IpCgNlS995ca1L1hnG3QElS1SzgXkcupn pca6pPXO2/1VKZzPUC0r7mfx6TGryM7+6nW8uZwFK/Gb9rjeF0BZA4jaowUOgzlY8N5p 3yKA== 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 b1si19574441edm.271.2019.09.15.02.44.30; Sun, 15 Sep 2019 02:45:09 -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 S1725835AbfIOJbS (ORCPT + 99 others); Sun, 15 Sep 2019 05:31:18 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:45156 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725497AbfIOJbS (ORCPT ); Sun, 15 Sep 2019 05:31:18 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8F9UvR6021757; Sun, 15 Sep 2019 11:30:57 +0200 Date: Sun, 15 Sep 2019 11:30:57 +0200 From: Willy Tarreau To: Lennart Poettering Cc: "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Linus Torvalds , "Alexander E. Patrakov" , Michael Kerrisk , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: [PATCH RFC v3] random: getrandom(2): optionally block when CRNG is uninitialized Message-ID: <20190915093057.GF20811@1wt.eu> References: <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914122500.GA1425@darwi-home-pc> <008f17bc-102b-e762-a17c-e2766d48f515@gmail.com> <20190915052242.GG19710@mit.edu> <20190915081747.GA1058@darwi-home-pc> <20190915085907.GC29771@gardel-login> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190915085907.GC29771@gardel-login> 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 On Sun, Sep 15, 2019 at 10:59:07AM +0200, Lennart Poettering wrote: > We live in a world where people run HTTPS, SSH, and all that stuff in > the initrd already. It's where SSH host keys are generated, and plenty > session keys. It is exactly the type of crap that create this situation : making people developing such scripts believe that any random source was OK to generate these, and as such forcing urandom to produce crypto-solid randoms! No, distro developers must know that it's not acceptable to generate lifetime crypto keys from the early boot when no entropy is available. At least with this change they will get an error returned from getrandom() and will be able to ask the user to feed entropy, or be able to say "it was impossible to generate the SSH key right now, the daemon will only be started once it's possible", or "the SSH key we produced will not be saved because it's not safe and is only usable for this recovery session". > If Linux lets all that stuff run with awful entropy then > you pretend things where secure while they actually aren't. It's much > better to fail loudly in that case, I am sure. This is precisely what this change permits : fail instead of block by default, and let applications decide based on the use case. > Quite frankly, I don't think this is something to fix in the > kernel. As long as it offers a single API to return randoms, and that it is not possible not to block for low-quality randoms, it needs to be at least addressed there. Then userspace can adapt. For now userspace does not have this option just due to the kernel's way of exposing randoms. Willy