linux-hardening - Re: [PATCH v2] slab: Decouple slab_debug and no_hash

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <202504161048.B7A4CAFB@keescook>
Date: Wed, 16 Apr 2025 10:52:09 -0700
From: Kees Cook <kees@...nel.org>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergio Perez Gonzalez <sperezglz@...il.com>,
	Vlastimil Babka <vbabka@...e.cz>,
	David Rientjes <rientjes@...gle.com>,
	Bagas Sanjaya <bagasdotme@...il.com>,
	Jonathan Corbet <corbet@....net>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
	Rasmus Villemoes <linux@...musvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@...omium.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Harry Yoo <harry.yoo@...cle.com>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Randy Dunlap <rdunlap@...radead.org>,
	Tamir Duberstein <tamird@...il.com>,
	Miguel Ojeda <ojeda@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
	linux-doc@...r.kernel.org, linux-mm@...ck.org,
	Thomas Huth <thuth@...hat.com>,
	"Borislav Petkov (AMD)" <bp@...en8.de>,
	Ard Biesheuvel <ardb@...nel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Stephen Boyd <swboyd@...omium.org>, linux-kernel@...r.kernel.org,
	linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2] slab: Decouple slab_debug and no_hash_pointers

On Wed, Apr 16, 2025 at 02:06:21PM +0200, Petr Mladek wrote:
> On Tue 2025-04-15 10:02:33, Kees Cook wrote:
> > Some system owners use slab_debug=FPZ (or similar) as a hardening option,
> > but do not want to be forced into having kernel addresses exposed due
> > to the implicit "no_hash_pointers" boot param setting.[1]
> > 
> > Introduce the "hash_pointers" boot param, which defaults to "auto"
> > (the current behavior), but also includes "always" (forcing on hashing
> > even when "slab_debug=..." is defined), and "never". The existing
> > "no_hash_pointers" boot param becomes an alias for "hash_pointers=never".
> > 
> > This makes it possible to boot with "slab_debug=FPZ hash_pointers=always".
> > 
> > Link: https://github.com/KSPP/linux/issues/368 [1]
> > Fixes: 792702911f58 ("slub: force on no_hash_pointers when slub_debug is enabled")
> > Co-developed-by: Sergio Perez Gonzalez <sperezglz@...il.com>
> > Signed-off-by: Sergio Perez Gonzalez <sperezglz@...il.com>
> > Acked-by: Vlastimil Babka <vbabka@...e.cz>
> > Acked-by: David Rientjes <rientjes@...gle.com>
> > Reviewed-by: Bagas Sanjaya <bagasdotme@...il.com>
> > Signed-off-by: Kees Cook <kees@...nel.org>
> 
> Tested-by: Petr Mladek <pmladek@...e.com>
> Reviewed-by: Petr Mladek <pmladek@...e.com>
> 
> I am going to wait few more days for a potential feedback.
> I'll queue it for 6.16 unless anyone complains.

Thanks very much!

> See a rant below ;-)
> [...]
> I personally do not like that these two parameters do not have the
> real effect until hash_pointers_finalize() is called at some
> "random" "unrelated" location, namely kmem_cache_init().
> But I could live with it.

Yeah, this is mainly due to slab_debug wanting to be able to control it.
I'd prefer they weren't linked at all, but it's also not too
unreasonable.

> But the alternative solution proposed at
> https://lore.kernel.org/r/Z_0AFjai6Bvg-YLD@pathway.suse.cz
> was hairy another way.
> 
> We could always improve it when it causes troubles.

Right. My thinking is that if another subsystem comes along with the
same compelling complaint as kmem, we can look at it again then. IMO,
really only an allocator should be in charge of such a large knob --
its whole job is managing pointers. :)

-Kees

-- 
Kees Cook