linux-kernel - Re: early x86 unseeded randomness

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, 15 Aug 2017 22:48:42 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Ingo Molnar <mingo@...nel.org>, Willy Tarreau <w@....eu>
Cc:     Theodore Ts'o <tytso@....edu>, Borislav Petkov <bp@...en8.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        x86-ml <x86@...nel.org>, "Jason A. Donenfeld" <Jason@...c4.com>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: early x86 unseeded randomness

Ingo Molnar <mingo@...nel.org> writes:

> * Willy Tarreau <w@....eu> wrote:
>
>> Nowadays we could use similar methods using RDTSC providing more accurate
>> counting. This doesn't provide a lot of entropy of course, given that a
>> 2 GHz machine will at most count 31 bits there. But I tend to think that
>> what matters during early boot is to transform something highly predictable
>> into something unlikely to be predicted (ie: an exploit having to scan 2^31
>> possible addresses will not be really usable). It's also possible to do the
>> same with the PIT0 counter ticking at 18.2 Hz without any correlation with
>> the RTC by the way, and roughly provide 25 more bits. And if you expect
>> that the BIOS has emitted a 800 Hz beep at boot, you could still have a
>> divider of 1491 in PIT2 providing 10 more bits, though with a bit of
>> correlation with PIT0 since they use the same 1.19 MHz source. These
>> methods increase the boot time by up to one second though, but my point
>> here is that when you have nothing it's always a bit better.
>
> One other thing besides trying to extract entropy via timing would be to utilize 
> more of the machine's environment in seeding the random number generator.
>
> For example on x86 the E820 table is available very early on and its addresses 
> could be mixed into the random pool. An external attacker often would not know the 
> precise hardware configuration.
>
> Likewise the boot parameters string could be mixed into the initial random pool as 
> well - and this way distributions could create per installation seed simply by 
> appending a random number to the boot string.

In fact that could be a per-boot seed, if you just re-ran update-grub in
the shutdown scripts with a new value.

cheers