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: <20170815064437.GA1986@1wt.eu>
Date:   Tue, 15 Aug 2017 08:44:37 +0200
From:   Willy Tarreau <w@....eu>
To:     "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

Hi Ted,

On Mon, Aug 14, 2017 at 09:31:24PM -0400, Theodore Ts'o wrote:
> The real fix is to do what OpenBSD does, which is to teach the
> bootloader (e.g., grub) to read from some file such as
> /var/lib/urandom/random-seed, and then to have the init scripts
> overwrite it with a new set of entropy generated from getrandom(2) as
> early as possible.
> 
> It won't solve the CD-ROM install problem (although there is enough
> entropy during the install process that after the install is done, we
> should be fine, and again, *hopefully* the distro people won't be
> stupid enough to generate high-value keys during the installation
> process, or certainly not early in the installation process).  But it
> does solve most of the problem.

In my opinion what matters is to combine multiple sources of entropy. I
remember in the good old days when I was coding under DOS, I used to
build my own random numbers using a phase detection method, counting
the time it takes for the RTC to switch to the next second, similar to
this :

  rand:
     xor edx, edx
     mov al, 0
     out 70h, al
     in al, 71h
     mov ah, al
  count:
     inc edx
     in al, 71h
     cmp al, ah
     jz count
     mov eax, edx
     ret

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.

Willy