From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752617AbdHOMsq (ORCPT ); Tue, 15 Aug 2017 08:48:46 -0400 Received: from ozlabs.org ([103.22.144.67]:46111 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751196AbdHOMsp (ORCPT ); Tue, 15 Aug 2017 08:48:45 -0400 From: Michael Ellerman To: Ingo Molnar , Willy Tarreau Cc: "Theodore Ts'o" , Borislav Petkov , Linus Torvalds , x86-ml , "Jason A. Donenfeld" , lkml Subject: Re: early x86 unseeded randomness In-Reply-To: <20170815074254.6byayhspc5tdtjb5@gmail.com> References: <20170814173515.n3vcpz37xh33ayuq@pd.tnic> <20170814180048.m3igiaiunlyb5wur@pd.tnic> <20170814190013.zixopgjyq26ukxcj@pd.tnic> <20170815013124.2afytkibspxrikdn@thunk.org> <20170815064437.GA1986@1wt.eu> <20170815074254.6byayhspc5tdtjb5@gmail.com> User-Agent: Notmuch/0.21 (https://notmuchmail.org) Date: Tue, 15 Aug 2017 22:48:42 +1000 Message-ID: <87pobxt2s5.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar writes: > * Willy Tarreau 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