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 08:09:50 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Willy Tarreau <w@....eu>, 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

On Tue, Aug 15, 2017 at 10:05:46AM +0200, Ingo Molnar wrote:
> > > * 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....

All of this assumes that you have different clock crystals generating
all of these different clock sources.  Otherwise there can be a lot
less entropy than you expected.

> In practice it's much faster to process the e820 table and the boot
> string though - and should already give a way to gain very good
> inter-machine randomization. It would also cover odd things like
> weird machines such as virtualization environments that often have
> nothing in the first 1MB.

There is nothing wrong with doing this --- and architecture
maintainers are encouraged to call add_device_randomness() on any
piece of data which they think might help.  That being said, these
values don't change much (boot string) or at all (e820 table) between
boots, and if you have a large collection of machines that all have
the same hardware (say, Dell desktops), and the same distro installed
on them (say, Ubuntu), it doesn't give you as much inter-machine
randomization as you might expect.

And as far as virtualization environments are concerned, the attacker
can determine quite easily from the IP address range if a VM is being
run out of an Amazon, Google, or Microsoft data center.

Finally, in some cases, we need the entropy *very* early --- for
example for kASLR, right after we get control from the boot loader.
Which is why I believe that we really do need to have the bootloader
fetching random seed material from the root file system or some other
trusted store to solve the inter-boot randomness problem.

Again, if platform code and device drivers want to call
add_device_randomness() early in the boot process --- they should
absolutely be encouraged to do this.  It is a good thing.  *AND* it is
not sufficient by itself.

Cheers,

					- Ted