From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758517AbcHYXhI (ORCPT ); Thu, 25 Aug 2016 19:37:08 -0400 Received: from mail-ua0-f176.google.com ([209.85.217.176]:36379 "EHLO mail-ua0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758165AbcHYXg4 (ORCPT ); Thu, 25 Aug 2016 19:36:56 -0400 MIME-Version: 1.0 In-Reply-To: References: From: Sandy Harris Date: Thu, 25 Aug 2016 19:35:29 -0400 Message-ID: Subject: Re: Entropy sources (was: /dev/random - a new approach) To: "H. Peter Anvin" Cc: Jeffrey Walton , linux-crypto@vger.kernel.org, LKML , "Theodore Ts'o" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 25, 2016 at 5:30 PM, H. Peter Anvin wrote: > The network stack is a good source of entropy, *once it is online*. > However, the most serious case is while the machine is still booting, > when the network will not have enabled yet. > > -hpa One possible solution is at: https://github.com/sandy-harris/maxwell A small (< 700 lines) daemon that gets entropy from timer imprecision and variations in time for arithmetic (cache misses, interrupts, etc.) and pumps it into /dev/random. Make it the first userspace program started and all should be covered. Directory above includes a PDF doc with detailed rationale and some discussion of alternate solutions. Of course if you are dealing with a system-on-a-chip or low-end embedded CPU & the timer is really inadequate, this will not work well. Conceivably well enough, but we could not know that without detailed analysis for each chip in question.