linux-kernel - Re: [PATCH 2/3] lib/Kconfig.debug: disable LOCK_DEBUGGING

lists.openwall.net		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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 21 Jun 2024 09:23:25 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Alexander Potapenko <glider@...gle.com>
Cc: elver@...gle.com, dvyukov@...gle.com, dave.hansen@...ux.intel.com,
 peterz@...radead.org, akpm@...ux-foundation.org, x86@...nel.org,
 linux-kernel@...r.kernel.org, kasan-dev@...glegroups.com,
 "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
 Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
 Boqun Feng <boqun.feng@...il.com>
Subject: Re: [PATCH 2/3] lib/Kconfig.debug: disable LOCK_DEBUGGING_SUPPORT
 under KMSAN

On 6/21/24 02:49, Alexander Potapenko wrote:
>  config LOCK_DEBUGGING_SUPPORT
>  	bool
> -	depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
> +	depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT && !KMSAN
>  	default y

This kinda stinks.  Practically, it'll mean that anyone turning on KMSAN
will accidentally turn off lockdep.  That's really nasty, especially for
folks who are turning on debug options left and right to track down
nasty bugs.

I'd *MUCH* rather hide KMSAN:

config KMSAN
        bool "KMSAN: detector of uninitialized values use"
        depends on HAVE_ARCH_KMSAN && HAVE_KMSAN_COMPILER
        depends on DEBUG_KERNEL && !KASAN && !KCSAN
        depends on !PREEMPT_RT
+	depends on !LOCKDEP

Because, frankly, lockdep is way more important than KMSAN.

But ideally, we'd allow them to coexist somehow.  Have we even discussed
the problem with the lockdep folks?  For instance, I'd much rather have
a relaxed lockdep with no checking in pfn_valid() than no lockdep at all.