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