Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5991690ybe; Tue, 17 Sep 2019 17:36:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqzYMX8truGF5mX03n7/OBORIOlLpi7yAH8l2uRNfOOoeVshPcroM3yE91D3YNACob30T2Kh X-Received: by 2002:a17:906:4ec2:: with SMTP id i2mr77213ejv.83.1568766977383; Tue, 17 Sep 2019 17:36:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568766977; cv=none; d=google.com; s=arc-20160816; b=UgFxgX63cRkGyItcMQZ/3peEJ9MkQ6CAKK4uNHRYJYYUJI/u1ql6NdcXaqXlGCwGMP vNAuW8Vi70/m1K91ZAdEdzNAOQpWzRULocb36AXXsgHEyA315NIfhRCAZlhkpAkzLKxb rmsMMLOKArH9UDGvDJTfOvPDn03OZKzDpoWHO8gNaftylSWWwCJoRyuP4ACVlHfPCBJQ TMiAdzKnHowUH7GoeqftwoFy1VE3QQgJoVl4QWxLE2IB9RTJHsp3k6QBqKR5HoS2lsHh lhwVmSmsg9/0cAyS2ljoMoD8BOUR8XHz+lznQMBnxzDDnDHmei8g+5SWrKdnlkn1/IXz SRYQ== 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=r5GtU8lgiaRtM2uHiyFfWke0Bm3Vp9RcqzCDVG4NfJs=; b=gSUOxIy4L+bjOI0VMvZzoB2LmxMii+qld9Y3Lr5nGv2HBPhy2OdkbaDJfRmOTc02cx wlo6RhqKvMuDQvkxXE5rPS/u+og+ebanztith5Cm2rMWbMYVjDhcSocd0K7lOOTxNdGf mQiTsjFjZFUz1Sti72+OcZoeYKXd2rEv+alMLTPy5ujrBRb2UWhA9TRtE+Y1un9pqLkh banoocwwJxpT+l+m0Juu3uOh1plXund5cjBzI3BVncuLE1/H55saVJT2k3WvDxy+Gwxg kJVKtKYJgNpn3IYnvlkB3fAFJQBC3URe8nwoAQVjVbghpOXkWvHiMF1xLReR5fvfGxw5 E/zQ== 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 53si2463784edz.275.2019.09.17.17.35.43; Tue, 17 Sep 2019 17:36:17 -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 S1727261AbfIQVih convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Sep 2019 17:38:37 -0400 Received: from luna.lichtvoll.de ([194.150.191.11]:48061 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726999AbfIQVig (ORCPT ); Tue, 17 Sep 2019 17:38: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 4277D77722; Tue, 17 Sep 2019 23:38:33 +0200 (CEST) From: Martin Steigerwald To: "Ahmed S. Darwish" Cc: Linus Torvalds , Lennart Poettering , "Theodore Y. Ts'o" , Willy Tarreau , Matthew Garrett , 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: Tue, 17 Sep 2019 23:38:33 +0200 Message-ID: <1722575.Y5XjozQscI@merkaba> In-Reply-To: <20190917205234.GA1765@darwi-home-pc> References: <2658007.Cequ2ms4lF@merkaba> <20190917205234.GA1765@darwi-home-pc> 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 Ahmed S. Darwish - 17.09.19, 22:52:34 CEST: > On Tue, Sep 17, 2019 at 10:28:47PM +0200, Martin Steigerwald wrote: > [...] > > > I don't have any kernel logs old enough to see whether whether crng > > init times have been different with Systemd due to asking for > > randomness for UUID/hashmaps. > > Please stop claiming this. It has been pointed out to you, __multiple > times__, that this makes no difference. For example: > > https://lkml.kernel.org/r/20190916024904.GA22035@mit.edu > > No. getrandom(2) uses the new CRNG, which is either initialized, > or it's not ... So to the extent that systemd has made systems > boot faster, you could call that systemd's "fault". > > You've claimed this like 3 times before in this thread already, and > multiple people replied with the same response. If you don't get the > paragraph above, then please don't continue replying further on this > thread. First off, this mail you referenced has not been an answer to a mail of mine. It does not have my mail address in Cc. So no, it has not been pointed out directly to me in that mail. Secondly: Pardon me, but I do not see how asking for entropy early at boot times or not doing so has *no effect* on the available entropy¹. And I do not see the above mail actually saying this. To my knowledge Sysvinit does not need entropy for itself². The above mail merely talks about the blocking on boot. And whether systemd-random-seed would drain entropy, not whether hashmaps/UUID do. And also not the effect that asking for entropy early has on the available entropy and on the *initial* initialization time of the new CRNG. However I did not claim that Systemd would block booting. *Not at all*. Thirdly: I disagree with the tone you use in your mail. And for that alone I feel it may be better for me to let go of this discussion. 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. However I am not even claiming anything. All I wrote above is that I do not have any measurements. But I'd expect that the more entropy is asked for early during boot, the longer the initial initialization of the new CRNG will take. And if someone else relies on this initialization, that something else would block for a longer time. I got that it the new crng won't block after that anymore. [1] https://github.com/systemd/systemd/issues/4167 (I know that it still with /dev/urandom, so if it is using RDRAND now, this may indeed be different, but would it then deplete entropy the CPU has available and that by default is fed into the Linux crng as well (even without trusting it completely)?) [2] According to https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html sysvinit does not contain a single line of code about entropy or random numbers. Daniel even updated his blog post with a hint to this discussion. Thanks, -- Martin