[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
