From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753498AbdHOGpA (ORCPT ); Tue, 15 Aug 2017 02:45:00 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:35472 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753283AbdHOGo4 (ORCPT ); Tue, 15 Aug 2017 02:44:56 -0400 Date: Tue, 15 Aug 2017 08:44:37 +0200 From: Willy Tarreau To: "Theodore Ts'o" , Borislav Petkov , Linus Torvalds , x86-ml , "Jason A. Donenfeld" , lkml Subject: Re: early x86 unseeded randomness Message-ID: <20170815064437.GA1986@1wt.eu> References: <20170814173515.n3vcpz37xh33ayuq@pd.tnic> <20170814180048.m3igiaiunlyb5wur@pd.tnic> <20170814190013.zixopgjyq26ukxcj@pd.tnic> <20170815013124.2afytkibspxrikdn@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170815013124.2afytkibspxrikdn@thunk.org> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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