[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+PQ1unqbJa6hh9OMxBx3+sKUmfycjFAb1FFH0e5C0FtQ@mail.gmail.com>
Date: Tue, 20 Jun 2017 11:14:37 -0700
From: Kees Cook <keescook@...omium.org>
To: Sandy Harris <sandyinchina@...il.com>
Cc: Jeffrey Walton <noloader@...il.com>, "Theodore Ts'o" <tytso@....edu>,
"Jason A. Donenfeld" <Jason@...c4.com>, tglx@...akpoint.cc, David Miller <davem@...emloft.net>,
Linus Torvalds <torvalds@...ux-foundation.org>, Eric Biggers <ebiggers3@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Michael Ellerman <mpe@...erman.id.au>
Subject: Re: Re: [PATCH] random: silence compiler warnings
and fix race
On Tue, Jun 20, 2017 at 10:50 AM, Sandy Harris <sandyinchina@...il.com> wrote:
> On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton <noloader@...il.com> wrote:
>> On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o <tytso@....edu> wrote:
>>> 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.
>
>> Are there compelling reasons a single dmesg warning cannot be provided?
>>
>> A single message avoids spamming the logs. It also informs the system
>> owner of the problem. An individual or organization can then take
>> action based on their risk posture. Finally, it avoids the kernel
>> making policy decisions for a user or organization.
>
> I'd say the best solution is to have no configuration option
> specifically for these messages. Always give some, but let
> DEBUG_KERNEL control how many.
>
> If DEBUG_KERNEL is not set, emit exactly one message & ignore any
> other errors of this type. On some systems, that message may have to
> be ignored, on some it might start an incremental process where one
> problem gets fixed only to have another crop up & on some it might
> prompt the admin to explore further by compiling with DEBUG_KERNEL.
>
> If DEBUG_KERNEL is set, emit a message for every error of this type.
How about doing this:
default DEBUG_KERNEL
Most distro kernel select DEBUG_KERNEL because it unhides a bunch of
other useful configs. Since it doesn't strictly _depend_ on
DEBUG_KERNEL, I think it's probably a mistake to enforce a false
dependency. Using it as a hint for the default seems maybe like a good
middle ground. (And if people can't agree on that, then I guess
"default n"...)
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
