From: Kees Cook <keescook@chromium.org>
To: Peter Gerber <peter@arbtirary.ch>
Cc: kernel-hardening@lists.openwall.com, linux-hardening@vger.kernel.org
Subject: Re: Kernel Self Protection Project: slub_debug=ZF
Date: Tue, 12 Apr 2022 17:16:56 -0700 [thread overview]
Message-ID: <202204121715.11B2CA80@keescook> (raw)
In-Reply-To: <6b039403-b46e-e186-63d0-91362dfe18a1@arbtirary.ch>
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
parent reply other threads:[~2022-04-13 0:17 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <6b039403-b46e-e186-63d0-91362dfe18a1@arbtirary.ch>]
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=202204121715.11B2CA80@keescook \
--to=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-hardening@vger.kernel.org \
--cc=peter@arbtirary.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox