Messages in this thread | | | Date | Wed, 8 Feb 2023 23:58:54 +0000 | From | Hyeonggon Yoo <> | Subject | Re: [PATCH] Revert "slub: force on no_hash_pointers when slub_debug is enabled" |
| |
On Wed, Feb 08, 2023 at 11:47:17AM -0800, Kees Cook wrote: > This reverts commit 792702911f581f7793962fbeb99d5c3a1b28f4c3. > > Linking no_hash_pointers() to slub_debug has had a chilling effect > on using slub_debug features for security hardening, since system > builders are forced to choose between redzoning and heap address location > exposures. Instead, just require that the "no_hash_pointers" boot param > needs to be used to expose pointers during slub_debug reports. > > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Stephen Boyd <swboyd@chromium.org> > Cc: concord@gentoo.org > Cc: Pekka Enberg <penberg@kernel.org> > Cc: David Rientjes <rientjes@google.com> > Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> > Cc: Petr Mladek <pmladek@suse.com> > Cc: linux-mm@kvack.org > Cc: stable@vger.kernel.org > Link: https://lore.kernel.org/lkml/202109200726.2EFEDC5@keescook/ > Signed-off-by: Kees Cook <keescook@chromium.org>
in the commit message:
> Obscuring the pointers that slub shows when debugging makes for some > confusing slub debug messages: > > Padding overwritten. 0x0000000079f0674a-0x000000000d4dce17 > > Those addresses are hashed for kernel security reasons. If we're trying > to be secure with slub_debug on the commandline we have some big > problems given that we dump whole chunks of kernel memory to the kernel > logs.
it dumps parts of kernel memory anyway and I'm not sure if slub_debug is supposed to be used for security hardening.
what about introducing new boot parameter like, slub_hardening, which does not print anything?
| |