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]

Message-ID: <20170815074254.6byayhspc5tdtjb5@gmail.com>
Date:   Tue, 15 Aug 2017 09:42:54 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     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


* 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.

Both methods should be very fast and robust.

Thanks,

	Ingo