Linux Hardening
 help / color / mirror / Atom feed
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

           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