From: Sandy Harris Subject: Re: get_random_bytes returns bad randomness before seeding is complete Date: Sat, 3 Jun 2017 17:45:43 -0400 Message-ID: References: <20170602172616.47qcxav6adq52nmk@thunk.org> <20170602190734.6zll7zc5hr66oacl@thunk.org> <20170603050433.4xpvloul25s47f2z@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: "Theodore Ts'o" , Stephan Mueller , Linux Crypto Mailing List , LKML , kernel-hardening@lists.openwall.com To: "Jason A. Donenfeld" Return-path: Received: from mail-wr0-f172.google.com ([209.85.128.172]:33861 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751162AbdFCVpp (ORCPT ); Sat, 3 Jun 2017 17:45:45 -0400 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: Stephan's driver, the HAVEGE system & several others purport to extract entropy from a series of timer calls. Probably the best analysis is in the Mcguire et al. paper at https://static.lwn.net/images/conf/rtlws11/random-hardware.pdf & the simplest code in my user-space driver at https://github.com/sandy-harris/maxwell The only kernel-space code I know of is Stephan's. If the claim that such calls give entropy is accepted (which I think it should be) then if we get one bit per call, need 100 or so bits & space the calls 100 ns apart, loading up a decent chunk of startup entropy takes about 10,000 ns or 10 microseconds which looks like an acceptable delay. Can we just do that very early in the boot process? Of course this will fail on systems with no high-res timer. Are there still some of those? It might be done in about 1000 times as long on a system that lacks the realtime library's nanosecond timer but has the Posix standard microsecond timer, implying a delay time in the milliseconds. Would that be acceptable in those cases?