Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp619644ybe; Thu, 19 Sep 2019 00:42:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqysHE4zygKRUqnzgvWVIMIu+wkPudyX//YQjf9tWhfvBFhXwQTfhuznYabLGFZulDd5wNe1 X-Received: by 2002:a17:906:154c:: with SMTP id c12mr126887ejd.129.1568878967304; Thu, 19 Sep 2019 00:42:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568878967; cv=none; d=google.com; s=arc-20160816; b=Y7rZ75yqgP7oAEFVXYF65iJt5/L8kax9Xvo8LYFPT9cgTwBJqAdcaPaJbVOKIrndkl hWvhnI+pXUNU0JTGd865J2h5wLBizynwRyV38fSuIvVAvCfu9RBomIbOFxqT6O+3o+Bz EaCRr3yZF3vXhaJZSKPSKZ4C9SaVCT9Ul4+9kadIVG+o5lvBCgmsAppzMCXvhxn1d7vf z1AbYIugE8+r0Nhf589IR6d8dSvLhwaRfrvYyex2TK+zX2Ih/hI/6HhdSdb9hkWmZmFR tuxK91VBqCahT1mByoQED8qnAiGKLg944pEMMyXtwr5oKSgR/INwjlndC+3h7AOddjRB i4ww== 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=HjPCko7LymZwYkoVBt4knyOzIvSyzBQ0Wl4eEYxSOo4=; b=OhNc3wsE0SLgZB2/ilKOAxuhR0+N/vVPXUW1fgZ9pAWIziPVZE55AWy7Kaqwx+rhtG BqpT9Izf4H6CXDuNL0s7u9nfG9qOXchyH6w2t6rXMP/pmcP2vELYD0nptC9siw2B5961 i/NxTzQFdFjheokl6zxNJPi7NMw16tf2i5/zoq2MP15fm+J3c5suT4yhqwoZTeodJ4MY Rki+SGInAViRvWd/UvTc3jqLDtG+sVA7luokKY98/n//lEO719T2etGaC6O57gAVTx7u F6mhuLh5nEKdFjqfEbGetPVj8j0QM3G26wyJyhwy5e5NRMQ+6qE8LBR2xEHOxNft1XEo /kSQ== 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 z10si4676555edx.168.2019.09.19.00.42.20; Thu, 19 Sep 2019 00:42:47 -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 S1727165AbfISH2H convert rfc822-to-8bit (ORCPT + 99 others); Thu, 19 Sep 2019 03:28:07 -0400 Received: from luna.lichtvoll.de ([194.150.191.11]:34167 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732034AbfISH2H (ORCPT ); Thu, 19 Sep 2019 03:28:07 -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 2A05677F1C; Thu, 19 Sep 2019 09:28:04 +0200 (CEST) From: Martin Steigerwald To: Lennart Poettering Cc: Matthew Garrett , "Ahmed S. Darwish" , Linus Torvalds , "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: Thu, 19 Sep 2019 09:28:03 +0200 Message-ID: <4837188.Q7355LDvlW@merkaba> In-Reply-To: <20190918135325.GC32346@gardel-login> References: <3783292.MWR84v24fu@merkaba> <20190918135325.GC32346@gardel-login> 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 Dear Lennart. Lennart Poettering - 18.09.19, 15:53:25 CEST: > On Mi, 18.09.19 00:10, Martin Steigerwald (martin@lichtvoll.de) wrote: > > > 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 > > Actually things are more complex. In systemd there are four classes of > random values we need: > > 1. High "cryptographic" quality. There are very few needs for this in […] > 2. High "non-cryptographic" quality. This is used for example for […] > 3. Medium quality. This is used for seeding hash tables. These may be […] > 4. Crap quality. There are only a few uses of this, where rand_r() is > is OK. > > Of these four case, the first two might block boot. Because the first > case is not common you won't see blocking that often though for > them. The second case is very common, but since we use RDRAND you > won't see it on any recent Intel machines. > > Or to say this all differently: the hash table seeding and the uuid > case are two distinct cases in systemd, and I am sure they should be. Thank you very much for your summary of uses of random numbers in Systemd and also for your other mail that "neither RDRAND nor /dev/ urandom know a concept of of "depleting entropy"". I thought they would deplete entropy needed to the initial seeding of crng. Thank you also for taking part in this discussion, even if someone put your mail address on carbon copy without asking with. I do not claim I understand enough of this random number stuff. But I feel its important that kernel and userspace developers actually talk with each other about a sane approach for it. And I believe that the complexity involved is part of the issue. I feel an API for attaining random number with different quality levels needs to be much, much, much more simple to use *properly*. I felt a bit overwhelmed by the discussion (and by what else is happening in my life, just having come back from holding a Linux performance workshop in front of about two dozen people), so I intend to step back from it. If one of my mails actually helped to encourage or facilitate kernel space and user space developers talking with each other about a sane approach to random numbers, then I may have used my soft skills in a way that brings some benefit. For the technical aspects certainly people are taking part in this discussion who are much much deeper into the intricacies of entropy in Linux and computers in general, so I just hope for a good outcome. Best, -- Martin