Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2017 11:14:37 -0700
From: Kees Cook <>
To: Sandy Harris <>
Cc: Jeffrey Walton <>, "Theodore Ts'o" <>, 
	"Jason A. Donenfeld" <>,, David Miller <>, 
	Linus Torvalds <>, Eric Biggers <>, 
	LKML <>, 
	Greg Kroah-Hartman <>, 
	"" <>, 
	Linux Crypto Mailing List <>, Michael Ellerman <>
Subject: Re: Re: [PATCH] random: silence compiler warnings
 and fix race

On Tue, Jun 20, 2017 at 10:50 AM, Sandy Harris <> wrote:
> On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton <> wrote:
>> On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o <> 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 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.