lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Apr 2019 15:21:09 -0700
From:   Kees Cook <>
To:     Josh Triplett <>
Cc:     Sinan Kaya <>, Kees Cook <>,
        LKML <>,
        Masahiro Yamada <>,
        Andrew Morton <>,
        "Peter Zijlstra (Intel)" <>,
        Johannes Weiner <>,
        Nicholas Piggin <>,
        Mathieu Desnoyers <>,
        Vasily Gorbik <>,
        Adrian Reber <>,
        Richard Guy Briggs <>,
        Petr Mladek <>,
        Andy Shevchenko <>,
        Matthew Wilcox <>,
        Joe Lawrence <>,
        Randy Dunlap <>,
        Mikulas Patocka <>,
        Robin Murphy <>,
        Tetsuo Handa <>,
        Changbin Du <>,
        Frederic Weisbecker <>,
        Sam Ravnborg <>, Ingo Molnar <>
Subject: Re: [PATCH v2] init: Do not select DEBUG_KERNEL by default

On Thu, Apr 11, 2019 at 3:16 PM Josh Triplett <> wrote:
> On Wed, Apr 10, 2019 at 11:13:52PM -0400, Sinan Kaya wrote:
> > On 4/10/2019 11:02 PM, Josh Triplett wrote:
> > > Then let's fix*that*, and get checkpatch to help enforce it in the future. EXPERT doesn't affect code generation, and neither should this.
> >
> > I think we have to do both. We need to go after the users as well as
> > solve the immediate problem per this patch.
> >
> > As Mathieu identified, CONFIG_DEBUG_KERNEL is being used all over the
> > place and getting subsystem owners to remove let alone add a check
> > to checkpatch is just going to take time.
> >
> > Please let us know if you are OK with this plan.
> I'm not OK with this plan. Turning on EXPERT should make the options
> under DEBUG_KERNEL visible; it's a bug that DEBUG_KERNEL affects code
> generation as well.
> Proposed alternative plan: let's add a new symbol, something like
> DEBUG_MISC ("Miscellaneous debug code that should be under a more
> specific debug option but isn't"), make it depend on DEBUG_KERNEL and be
> "default DEBUG_KERNEL" but allow itself to be turned off, and then
> mechanically change the small handful of "#ifdef CONFIG_DEBUG_KERNEL" to
> Does that sound like an appropriately rapid solution for this bug?

Sure, that sounds fine to me. Sinan can you take care of that for v4?

Kees Cook

Powered by blists - more mailing lists