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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 18 Sep 2019 13:13:30 -0700
From:   Linus Torvalds <>
To:     "Eric W. Biederman" <>
Cc:     Lennart Poettering <>,
        "Ahmed S. Darwish" <>,
        "Theodore Y. Ts'o" <>, Willy Tarreau <>,
        Matthew Garrett <>,
        Vito Caputo <>,
        Andreas Dilger <>,
        Jan Kara <>, Ray Strode <>,
        William Jon McCann <>,
        "Alexander E. Patrakov" <>,
        zhangjs <>,,
        lkml <>
Subject: Re: Linux 5.3-rc8

On Wed, Sep 18, 2019 at 12:56 PM Eric W. Biederman
<> wrote:
> The cheap solution appears to be copying a random seed from a previous
> boot, and I think that will take care of many many cases, and has
> already been implemented.  Which reduces this to a system first
> boot issue.

Not really.

Part of the problem is that many people don't _trust_ that "previous
boot entropy".

The lack of trust is sometimes fundamental mistrust ("Who knows where
it came from"), which also tends to cover things like not trusting
rdrand or not trusting the boot loader claimed randomness data.

But the lack of trust has been realistic - if you generated your disk
image by cloning a pre-existing one, you may well have two (or more -
up to any infinite number) of subsequent boots that use the same
"random" data for initialization.

And doing that "boot a pre-existing image" is not as unusual as you'd
think. Some people do it to make bootup faster - there have been
people who work on pre-populating bootup all the way to user mode by
basically making boot be a "resume from disk" kind of event.

So a large part of the problem is that we don't actually trust things
that _should_ be trust-worthy, because we've seen (over and over
again) people mis-using it. So then we do mix in the data into the
randomness pool (because there's no downside to _that_), but we don't
treat it as entropy (because while it _probably_ is, we don't actually
trust it sufficiently).

A _lot_ of the problems with randomness come from these trust issues.
Our entropy counting is very very conservative indeed.


Powered by blists - more mailing lists