linux-kernel - 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]

Date:   Tue, 17 Sep 2019 13:58:45 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Lennart Poettering <mzxreary@...inter.de>
Cc:     "Ahmed S. Darwish" <darwish.07@...il.com>,
        "Theodore Y. Ts'o" <tytso@....edu>, Willy Tarreau <w@....eu>,
        Matthew Garrett <mjg59@...f.ucam.org>,
        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

Side note, and entirely unrelated to this particular problem, but
_because_ I was looking at the entropy init and sources of randomness
we have, I notice that we still don't use the ToD clock as a source.

There's not a whole lot of bits there, but at least one of the attacks
against entirely missing boot-time randomness was to look at the
output of get_random_bytes(), and just compare it across machines. We
sanitize things by going through a cryptographic hash function, but
that helps hide the internal entropy buffers from direct viewing, but
it still leaves the "are those internal entropy buffers the _same_
across machines" for the nasty embedded hardware case with identical
hardware.

Of course, some of those machines didn't even have a a time-of-day
clock either. But the fact that some didn't doesn't mean we shouldn't
take it into account.

So adding a "add_device_randomness()" to do_settimeofday64() (which
catches them all) wouldn't be a bad idea. Not perhaps "entropy", but
helping against detecting the case of basically very limited entropy
at all at early boot.

I'm pretty sure we discussed that case when we did those things
originally, but I don't actually see us doing it anywhere right now.

So we definitely have some sources of differences for different
systems that we could/should use, even if we might not be able to
really account them as "entropy". The whole "people generated a number
of the same keys" is just horrendously bad, even if they were to use
/dev/urandom that doesn't have any strict entropy guarantees.

               Linus