From: Kees Cook <kees@kernel.org>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: Petr Mladek <pmladek@suse.com>,
Sergio Perez Gonzalez <sperezglz@gmail.com>,
Vlastimil Babka <vbabka@suse.cz>,
David Rientjes <rientjes@google.com>,
Bagas Sanjaya <bagasdotme@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Steven Rostedt <rostedt@goodmis.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
"Paul E. McKenney" <paulmck@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Tamir Duberstein <tamird@gmail.com>,
Miguel Ojeda <ojeda@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
linux-doc@vger.kernel.org, linux-mm@kvack.org,
Thomas Huth <thuth@redhat.com>,
"Borislav Petkov (AMD)" <bp@alien8.de>,
Ard Biesheuvel <ardb@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andreas Hindborg <a.hindborg@kernel.org>,
Stephen Boyd <swboyd@chromium.org>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2] slab: Decouple slab_debug and no_hash_pointers
Date: Fri, 18 Apr 2025 13:13:20 -0700 [thread overview]
Message-ID: <202504181307.254F81843@keescook> (raw)
In-Reply-To: <aAEM73DrpbzdZF92@harry>
On Thu, Apr 17, 2025 at 11:15:11PM +0900, Harry Yoo wrote:
> On Tue, Apr 15, 2025 at 10:02:33AM -0700, 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]
>
> Is this behavior documented somewhere or it's only in the code?
> I couldn't find anything other than the code.
Hmm, that's an excellent point. I don't see any mention of it in
kernel-parameters.txt. Perhaps this?
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4568572205ee..982e6511a225 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -6483,6 +6483,10 @@
Documentation/mm/slub.rst.
(slub_debug legacy name also accepted for now)
+ Using this option implies the "no_hash_pointers"
+ option which can be undone by adding the
+ "hash_pointers=always" option.
+
slab_max_order= [MM]
Determines the maximum allowed order for slabs.
A high setting may cause OOMs due to memory
>
> > 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>
> > ---
>
> Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
>
> By the way, while this patch does not change existing behavior of
> slub_debug implying no_hash_pointers, kmem_cache_init() is not the only
> place that enables slub_debug_enabled static key.
>
> Maybe we should update __kmem_cache_create_args() too?
> (in a separate patch)
The state of pointer hashing should not change after boot. (It is
intentionally designed to use __ro_after_init.) Honestly, I'd prefer
that slab_debug was not tied to no_hash_pointers at all...
-Kees
--
Kees Cook
next prev parent reply other threads:[~2025-04-18 20:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 17:02 [PATCH v2] slab: Decouple slab_debug and no_hash_pointers Kees Cook
2025-04-16 12:06 ` Petr Mladek
2025-04-16 17:52 ` Kees Cook
2025-06-05 20:15 ` Kees Cook
2025-06-09 14:39 ` Petr Mladek
2025-06-09 15:24 ` Kees Cook
2025-06-09 20:12 ` Andy Shevchenko
2025-06-10 8:35 ` Petr Mladek
2025-04-17 12:36 ` Rafael Aquini
2025-04-17 14:15 ` Harry Yoo
2025-04-18 20:13 ` Kees Cook [this message]
2025-04-21 9:43 ` Harry Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202504181307.254F81843@keescook \
--to=kees@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=ardb@kernel.org \
--cc=bagasdotme@gmail.com \
--cc=bp@alien8.de \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=harry.yoo@oracle.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=ojeda@kernel.org \
--cc=paulmck@kernel.org \
--cc=penberg@kernel.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=sperezglz@gmail.com \
--cc=swboyd@chromium.org \
--cc=tamird@gmail.com \
--cc=thuth@redhat.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.