On 17/09/2019 22.58, Linus Torvalds wrote:
> 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.
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? Sure, for virtualized environments one
probably always gets zeroed pages from the host (otherwise the host has
a problem...), and on PCs maybe the BIOS interferes.
But for cheap embedded devices with non-ECC RAM and not a lot of
value-add firmware between power-on and start_kernel(), would it make
sense to read a few MB of memory outside of where the kernel was loaded
and feed those to add_device_randomness() (of course, doing it as early
as possible, maybe first thing in start_kernel())? Or do the reading in
the bootloader and pass on the sha256() in the DT/rng-seed property?
A quick "kitchen-table" experiment with the board I have on my desk
shows that there are at least some randomness to be had after a cold boot.
Maybe this has already been suggested and rejected?
Rasmus
On Wed, Sep 18, 2019 at 11:33:39AM +0200, Rasmus Villemoes wrote:
> On 17/09/2019 22.58, Linus Torvalds wrote:
> > 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.
>
> 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? Sure, for virtualized environments one
> probably always gets zeroed pages from the host (otherwise the host has
> a problem...), and on PCs maybe the BIOS interferes.
>
> But for cheap embedded devices with non-ECC RAM and not a lot of
> value-add firmware between power-on and start_kernel(), would it make
> sense to read a few MB of memory outside of where the kernel was loaded
> and feed those to add_device_randomness() (of course, doing it as early
> as possible, maybe first thing in start_kernel())? Or do the reading in
> the bootloader and pass on the sha256() in the DT/rng-seed property?
>
> A quick "kitchen-table" experiment with the board I have on my desk
> shows that there are at least some randomness to be had after a cold boot.
>
> Maybe this has already been suggested and rejected?
We've already discussed that point a few times. The issue is that
bootloaders and/or BIOSes tend to wipe everything. Ideally we should
let the boot loader collect entropy from the DDR training phase since
it's a period where noise is observed. It's also the right moment to
collect some random contents that may lie in the RAM cells.
Similarly asynchronous clocks driving external components can be used
as well if you can measure their phase with the CPU's clock.
Regards,
Willy
18.09.2019 15:16, Willy Tarreau пишет:
> We've already discussed that point a few times. The issue is that
> bootloaders and/or BIOSes tend to wipe everything. Ideally we should
> let the boot loader collect entropy from the DDR training phase since
> it's a period where noise is observed. It's also the right moment to
> collect some random contents that may lie in the RAM cells.
>
> Similarly asynchronous clocks driving external components can be used
> as well if you can measure their phase with the CPU's clock.
This does not correspond to my own observations. I have a setup where a
secondary key is saved into RAM for unlocking a LUKS container after a
reboot. It is documented by me (sorry, in Russian only) here:
https://habr.com/ru/post/457396/ , will publish an English translation
in my blog if I get at least one request (in private email, please).
The results so far are:
1. Desktop with MSI Z87I board: works.
2. Lenovo Yoga 2 Pro laptop: works.
3. Server based on the Intel Corporation S1200SPL board (available from
OVH as EG-32): does not work, memory is cleared.
4. Cheap server based on Gooxi G1SCN-B board (the cheapes thing with
IPMI available on bacloud.com): works.
So that's 75% of success stories (found at least one page that is
preserved after the "reboot" command) based on my samples.
--
Alexander E. Patrakov
On Wed, Sep 18, 2019 at 03:25:51PM +0500, Alexander E. Patrakov wrote:
> The results so far are:
>
> 1. Desktop with MSI Z87I board: works.
> 2. Lenovo Yoga 2 Pro laptop: works.
> 3. Server based on the Intel Corporation S1200SPL board (available from OVH
> as EG-32): does not work, memory is cleared.
> 4. Cheap server based on Gooxi G1SCN-B board (the cheapes thing with IPMI
> available on bacloud.com): works.
>
> So that's 75% of success stories (found at least one page that is preserved
> after the "reboot" command) based on my samples.
That's pretty good! I didn't have this luck each time I tried this in
the past :-/ I remember noticing that video RAM from graphics card was
often usable however, which I figured I could use after seeing a ghost
image from a previous boot when switching to graphics mode.
Willy
On Wed, Sep 18, 2019 at 2:33 AM Rasmus Villemoes
<[email protected]> 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
maps.
And if you do it, it's not clear it will add any noise at all. It
_might_. But it might equally well not.
Linus