Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752694AbdFTJ6h (ORCPT ); Tue, 20 Jun 2017 05:58:37 -0400 Received: from imap.thunk.org ([74.207.234.97]:48970 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752227AbdFTJhH (ORCPT ); Tue, 20 Jun 2017 05:37:07 -0400 Date: Tue, 20 Jun 2017 05:36:42 -0400 From: "Theodore Ts'o" To: "Jason A. Donenfeld" Cc: noloader@gmail.com, tglx@breakpoint.cc, David Miller , Linus Torvalds , Eric Biggers , LKML , Greg Kroah-Hartman , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , Michael Ellerman Subject: Re: [PATCH] random: silence compiler warnings and fix race Message-ID: <20170620093642.3ri6dct5qkf7vhuc@thunk.org> Mail-Followup-To: Theodore Ts'o , "Jason A. Donenfeld" , noloader@gmail.com, tglx@breakpoint.cc, David Miller , Linus Torvalds , Eric Biggers , LKML , Greg Kroah-Hartman , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , Michael Ellerman References: <20170614192838.3jz4sxpcuhxygx4z@breakpoint.cc> <20170614224526.29076-1-Jason@zx2c4.com> <20170620060344.ngbnzg2mz5hvq4kw@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1506 Lines: 31 On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: > > Suppressing all messages for all configurations cast a wider net than > > necessary. Configurations that could potentially be detected and fixed > > likely will go unnoticed. If the problem is not brought to light, then > > it won't be fixed. > > I more or less agree with you that we should just turn this on for all > users and they'll just have to live with the spam and report odd > entries, and overtime we'll fix all the violations. Fix all the problems *how*? If you are on an old system which doesn't a hardware random number generator, and which doesn't have a high resolution cycle counter, and may not have a lot of entropy easily harvestable from the environment, there may not be a lot you can do. Sure, you can pretend that the cache (which by the way is usually determinstic) is ***so*** complicated that no one can figure it out, and essentially pretend that you have entropy when you probably don't; that just simply becomes a different way of handwaving and suppressing the warning messages. > But I think there's another camp that would mutiny in the face of this > kind of hubris. Blocking the boot for hours and hours until we have enough entropy to initialize the CRNG is ***not*** an acceptable way of making the warning messages go away. Do that and the users **will** mutiny. It's this sort of attitude which is why Linus has in the past said that security people are sometimes insane.... - Ted