Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752565AbdFTIxo (ORCPT ); Tue, 20 Jun 2017 04:53:44 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:52067 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706AbdFTIxk (ORCPT ); Tue, 20 Jun 2017 04:53:40 -0400 MIME-Version: 1.0 In-Reply-To: References: <20170614192838.3jz4sxpcuhxygx4z@breakpoint.cc> <20170614224526.29076-1-Jason@zx2c4.com> <20170620060344.ngbnzg2mz5hvq4kw@thunk.org> From: "Jason A. Donenfeld" Date: Tue, 20 Jun 2017 10:53:35 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] random: silence compiler warnings and fix race To: noloader@gmail.com Cc: "Theodore Ts'o" , tglx@breakpoint.cc, David Miller , Linus Torvalds , Eric Biggers , LKML , Greg Kroah-Hartman , kernel-hardening@lists.openwall.com, Linux Crypto Mailing List , Michael Ellerman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1108 Lines: 24 On Tue, Jun 20, 2017 at 10:33 AM, Jeffrey Walton wrote: > I think it is a bad idea to suppress all messages from a security > engineering point of view. > > Many folks don't run debug kernels. Most of the users who want or need > to know of the issues won't realize its happening. Consider, the > reason we learned of systemd's problems was due to dmesg's. > > 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. But I think there's another camp that would mutiny in the face of this kind of hubris. That's why I moved pretty readily toward the compromise position of default y, but depends on DEBUG_KERNEL. My hope was that it'd to an extent satisfy both camps, and also disappoint both camps in an equal way.