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?