linux-kernel - Re: [PATCH] mm/mm_init: Pull CONFIG_DEBUG_CHECK_PAGES out of CONFIG_DEBUG

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20251121232044.3120695-1-joshua.hahnjy@gmail.com>
Date: Fri, 21 Nov 2025 15:20:43 -0800
From: Joshua Hahn <joshua.hahnjy@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: David Hildenbrand <david@...nel.org>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
	Michal Hocko <mhocko@...e.com>,
	Mike Rapoport <rppt@...nel.org>,
	Suren Baghdasaryan <surenb@...gle.com>,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	kernel-team@...a.com,
	Kees Cook <kees@...nel.org>
Subject: Re: [PATCH] mm/mm_init: Pull CONFIG_DEBUG_CHECK_PAGES out of CONFIG_DEBUG_VM

On Fri, 21 Nov 2025 23:03:01 +0100 Vlastimil Babka <vbabka@...e.cz> wrote:

> On 11/21/25 21:44, Joshua Hahn wrote:
> > Use-after-free and double-free bugs can be very difficult to track down.
> > The kernel is good at tracking these and preventing bad pages from being
> > used/created through simple checks gated behind "check_pages_enabled".
> > 
> > Currently, the only ways to enable this flag is by building with
> > CONFIG_DEBUG_VM, or as a side effect of other checks such as
> > init_on_{alloc, free}, page_poisoning, or debug_pagealloc among others.
> > These solutions are powerful, but may often be too coarse in balancing
> > the performance vs. safety that a user may want, particularly in
> > latency-sensitie production environments.
> 
> OK. Would a boot parameter work for you instead? It's more flexible than a
> config option. Then we could perhaps also decouple it from
> init_on_alloc/init_on_free as it's a bit odd side-effect for those anyway.

Hi Vlastimil, thanks for the quick review!

Yes, I think a boot parameter would also work perfectly fine. There's nothing
in particular about making it a build config that I think is necessary here.
So happy to make it a boot parameter, and also decouple it like you suggested!

I'll spin up something and submit a v2. Thanks again for your review!
Joshua