linux-ext4 - Re: Linux 5.3-rc8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3783292.MWR84v24fu@merkaba>
Date:   Wed, 18 Sep 2019 00:10:33 +0200
From:   Martin Steigerwald <martin@...htvoll.de>
To:     Matthew Garrett <mjg59@...f.ucam.org>
Cc:     "Ahmed S. Darwish" <darwish.07@...il.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Lennart Poettering <mzxreary@...inter.de>,
        "Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
        Vito Caputo <vcaputo@...garu.com>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>,
        William Jon McCann <mccann@....edu>,
        "Alexander E. Patrakov" <patrakov@...il.com>,
        zhangjs <zachary@...shancloud.com>, linux-ext4@...r.kernel.org,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Linux 5.3-rc8

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