Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5993672ybe; Tue, 17 Sep 2019 17:39:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqy96xZbIoBD2ljSWw0ujLkDP+wU5nLFyamF3mbdlnTVC4wT9hVFqerFgGdzg4ifccPMBgKa X-Received: by 2002:aa7:d80d:: with SMTP id v13mr7784611edq.284.1568767141748; Tue, 17 Sep 2019 17:39:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568767141; cv=none; d=google.com; s=arc-20160816; b=EIOZpeLaI7b8VXGqjz0MYEwUyjA+foHBZxEc7YL54LuscEbQ/sBOAE7KC+9EKTRKvd z5UoRdelafQyREiqcSPA/gWiDSTDgKU9UtzGnZEfhfLQ72kBT1vAYIRyXPJqSk9obSUU KDyhKumVtkH/cPpP2Z3iylSwqLYIzOn+McIefA8stt5jSVZNEPSVu7LpBmE3I1hC55hx zpDQy4AfpClqUyqzehAfcyrtK4hqdl3byBT/dKjTJx2GnE3y4ZvEsdCLKoKkSLDg8ts+ 5g+0sGqvHc11qIW6L5yK0bElsqhf9pH6OZL0FWKpO1rDaJAtm/6bawsVX3a2ku2xkwxn oQ7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=oaNF3hpothFCA44r032mFolkdg0FTngDNR5kkm186Ik=; b=vtTPRv4xJSzZMRPiP1jsQLaauGYJPZ/lpH9bZcd4NHA283ZY4q622U+Y107elum1jA udoFBVfqaI8/lUqv9dg/grLIvJ4Ytov71PcbyI4u5foCA1r+Lv1fpCf1KHCrIcSaCBxA ccCOGzSnB2n/UcCDK2tgw+OEw7UjAY5nilyXuBO8QQG1T3GzS1Js8dpzFqoSOnFfX9zm 4OT/PdK6qQhBmpu707l7lImWtWILtKvqFucjskXi+0ET27zQb9NX66Q5JteOdIVnPDLy b215LKdQA4PxSn3jzQq432gZlpGD9u0FKcOxWJPSL8NdsfKJxFj5EQV/3gnk3TiuA/QX U16A== 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 n3si2237707edi.34.2019.09.17.17.38.37; Tue, 17 Sep 2019 17:39:01 -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 S1727425AbfIQWKg convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Sep 2019 18:10:36 -0400 Received: from luna.lichtvoll.de ([194.150.191.11]:40659 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727365AbfIQWKg (ORCPT ); Tue, 17 Sep 2019 18:10:36 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id DECBD77749; Wed, 18 Sep 2019 00:10:33 +0200 (CEST) From: Martin Steigerwald To: Matthew Garrett Cc: "Ahmed S. Darwish" , Linus Torvalds , Lennart Poettering , "Theodore Y. Ts'o" , Willy Tarreau , Vito Caputo , 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 Date: Wed, 18 Sep 2019 00:10:33 +0200 Message-ID: <3783292.MWR84v24fu@merkaba> In-Reply-To: <20190917215200.wtjim3t6zgt7gdmw@srcf.ucam.org> References: <1722575.Y5XjozQscI@merkaba> <20190917215200.wtjim3t6zgt7gdmw@srcf.ucam.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="UTF-8" Authentication-Results: mail.lichtvoll.de; auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Matthew Garrett - 17.09.19, 23:52:00 CEST: > On Tue, Sep 17, 2019 at 11:38:33PM +0200, Martin Steigerwald wrote: > > My understanding of entropy always has been that only a certain > > amount of it can be produced in a certain amount of time. If that > > is wrong… please by all means, please teach me, how it would be. > > getrandom() will never "consume entropy" in a way that will block any > users of getrandom(). If you don't have enough collected entropy to > seed the rng, getrandom() will block. If you do, getrandom() will > generate as many numbers as you ask it to, even if no more entropy is > ever collected by the system. So it doesn't matter how many clients > you have calling getrandom() in the boot process - either there'll be > enough entropy available to satisfy all of them, or there'll be too > little to satisfy any of them. Right, but then Systemd would not use getrandom() for initial hashmap/ UUID stuff since it 1) would block boot very early then, which is not desirable and 2) it does not need strong random numbers anyway. At least that is how I understood Lennart's comments on the Systemd bug report I referenced. AFAIK hashmap/UUID stuff uses *some* entropy *before* crng has been seeded with entropy and all I wondered was whether this using *some* entropy *before* crng has been seeded – by /dev/urandom initially, but now as far as I got with RDRAND if available – will delay the process of gathering the entropy necessary to seed crng… if that is the case then anything that uses crng during or soon after boot, like gdm, sddm, OpenSSH ssh-keygen will be blocked for a longer time will the initial seeding of crng has been done. Of course if hashmap/UUID stuff does not use any entropy that would be required for the *initial* seeding or crng, then… that would not be the case. But from what I understood, it does. And yes, for "systemd-random-seed" it is true that it does not drain entropy for getrandom, cause it writes the seed to disk *after* crng has been initialized, i.e. at a time where getrandom would never block again as long as the system is running. If I am still completely misunderstanding something there, then it may be better to go to sleep. Which I will do now anyway. Or I may just not be very good at explaining what I mean. -- Martin