|
Message-ID: <202204121715.11B2CA80@keescook> Date: Tue, 12 Apr 2022 17:16:56 -0700 From: Kees Cook <keescook@...omium.org> To: Peter Gerber <peter@...tirary.ch> Cc: kernel-hardening@...ts.openwall.com, linux-hardening@...r.kernel.org Subject: Re: Kernel Self Protection Project: slub_debug=ZF On Sun, Apr 10, 2022 at 09:34:17PM +0200, Peter Gerber wrote: > Hello, > > The Kernel Self Protection Project, on their Recommended Settings [1] page, > suggests the following: > > # Enable SLUB redzoning and sanity checking (slow; requires > CONFIG_SLUB_DEBUG=y above). > slub_debug=ZF > > On recent kernels, I see the following in dmesg when this option is set: > > ********************************************************** > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ** > ** ** > ** This system shows unhashed kernel memory addresses ** > ** via the console, logs, and other interfaces. This ** > ** might reduce the security of your system. ** > ** ** > ** If you see this message and you are not debugging ** > ** the kernel, report this immediately to your system ** > ** administrator! ** > ** ** > ** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ** > ********************************************************** > > A bit of digging tells me that this is caused by "slub: force on > no_hash_pointers when slub_debug is enabled" [2]. Assuming the performance > impact is acceptable, is this option still recommend? Should there perhaps > be a way to explicitly disable no_hash_pointers (e.g. via > no_hash_pointers=off)? Eww, that's not good at all. Would you be willing to write a patch to decouple this again? I think the primary issue is that these "debug" modes aren't exclusively used for debugging, and exposing the unhashed pointer is directly in conflict with the non-debug use case. :P -Kees > > Regards, > > Peter > > [1]: https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Recommended_Settings > [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=792702911f581f7793962fbeb99d5c3a1b28f4c3 -- Kees Cook
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.