[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAE-0n53Ou1qgueFZ7zL-rFwsit6XJnYZkRtggdx3XXvL7HWrow@mail.gmail.com>
Date: Mon, 9 May 2022 16:58:49 -0400
From: Stephen Boyd <swboyd@...omium.org>
To: Peter Gerber <peter@...itrary.ch>,
kernel-hardening@...ts.openwall.com,
linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Vlastimil Babka <vbabka@...e.cz>, linux-mm@...ck.org,
Petr Mladek <pmladek@...e.com>
Subject: Re: [PATCH] Decouple slub_debug= from no_hash_pointers again
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.
Powered by blists - more mailing lists