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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 18 Sep 2019 12:31:24 -0700
From:   Linus Torvalds <>
To:     Rasmus Villemoes <>
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 2:33 AM Rasmus Villemoes
<> wrote:
> And unrelated to the non-use of the RTC (which I agree seems weird), but
> because there's no better place in this thread: How "random" is the
> contents of RAM after boot?

It varies all over the place.

Some machines will most definitely clear it at each boot.

Others will clear it on cold boots but not warm boots.

Yet other environments never clear it at all, or leave it with odd patterns.

So it _could_ be useful as added input to the initial random state,
but it equally well might be totally pointless. It's really hard to
even guess.

There would be nothing wrong by trying to do add_device_randomness()
from some unused-at-boot memory area, but it's unclear what memory
area you should even attempt to use. Certainly not beginning of RAM or
end of RAM, which are both special and more likely to have been used
by the boot sequence even if it is then marked as unused in the memory

And if you do it, it's not clear it will add any noise at all. It
_might_. But it might equally well not.


Powered by blists - more mailing lists