kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Peter Gerber <peter@arbitrary.ch>,
	kernel-hardening@lists.openwall.com,
	 linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	 Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	 Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	linux-mm@kvack.org,  Petr Mladek <pmladek@suse.com>
Subject: Re: [PATCH] Decouple slub_debug= from no_hash_pointers again
Date: Mon, 9 May 2022 16:58:49 -0400	[thread overview]
Message-ID: <CAE-0n53Ou1qgueFZ7zL-rFwsit6XJnYZkRtggdx3XXvL7HWrow@mail.gmail.com> (raw)
In-Reply-To: <8e472c9e-2076-bc25-5912-8433adf7b579@arbitrary.ch>

Quoting Peter Gerber (2022-05-08 07:56:29)
> While, as mentioned in 792702911f58, no_hash_pointers is what
> one wants for debugging, this option is also used for hardening.
>
> Various places recommend or use slub_debug for hardening:
>
> a) The Kernel Self Protection Project lists slub_debug as
>    a recommended setting. [1]
> b) Debian offers package hardening-runtime [2] which enables
>    slub_debug for hardening.
> c) Security- and privacy-oriented Tails enables slub_debug
>    by default [3].
>
> I understand that encountering hashed pointers during debugging
> is most unwanted. Thus, I updated the documentation to make
> it as clear as possible that no_hash_pointers is what one
> wants when using slub_debug for debugging. I also added a
> mentioned of the hardening use case in order to discourage
> any other, well-meant, tries to disable hashing with slub_debug.

Why not add a CONFIG_HARDENED_SLUB option that enables poisoning and
also makes slub debugging not print any messages to the kernel log
containing object internal details? Then it can be enabled in the kernel
config to harden slub and if the flag is enabled we don't hash pointers
based on 'slub_debug' existing on the commandline? And maybe add some
commandline argument like 'slub_debug=H' for "hardened" so it can be
turned off as well if it is built into the config.

      reply	other threads:[~2022-05-09 21:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-08 14:56 [PATCH] Decouple slub_debug= from no_hash_pointers again Peter Gerber
2022-05-09 20:58 ` Stephen Boyd [this message]

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=CAE-0n53Ou1qgueFZ7zL-rFwsit6XJnYZkRtggdx3XXvL7HWrow@mail.gmail.com \
    --to=swboyd@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=peter@arbitrary.ch \
    --cc=pmladek@suse.com \
    --cc=rientjes@google.com \
    --cc=vbabka@suse.cz \
    /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;
as well as URLs for NNTP newsgroup(s).