Re: [PATCH v2] slab: Decouple slab_debug and no_hash_pointers

[Kees Cook <kees@kernel.org>]

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@gmail.com>
> > Signed-off-by: Sergio Perez Gonzalez <sperezglz@gmail.com>
> > Acked-by: Vlastimil Babka <vbabka@suse.cz>
> > Acked-by: David Rientjes <rientjes@google.com>
> > Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
> > Signed-off-by: Kees Cook <kees@kernel.org>
> 
> Tested-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Petr Mladek <pmladek@suse.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