[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+Q2xVKiN9UdZGwA@localhost>
Date: Wed, 8 Feb 2023 23:58:54 +0000
From: Hyeonggon Yoo <42.hyeyoo@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: Vlastimil Babka <vbabka@...e.cz>,
Stephen Boyd <swboyd@...omium.org>, concord@...too.org,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Petr Mladek <pmladek@...e.com>, linux-mm@...ck.org,
stable@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Christoph Lameter <cl@...ux.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Keith Busch <kbusch@...nel.org>, Jens Axboe <axboe@...nel.dk>,
Bart Van Assche <bvanassche@....org>,
Mikulas Patocka <mpatocka@...hat.com>,
Ard Biesheuvel <ardb@...nel.org>,
Mark Rutland <mark.rutland@....com>,
linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] Revert "slub: force on no_hash_pointers when slub_debug
is enabled"
On Wed, Feb 08, 2023 at 11:47:17AM -0800, Kees Cook wrote:
> This reverts commit 792702911f581f7793962fbeb99d5c3a1b28f4c3.
>
> Linking no_hash_pointers() to slub_debug has had a chilling effect
> on using slub_debug features for security hardening, since system
> builders are forced to choose between redzoning and heap address location
> exposures. Instead, just require that the "no_hash_pointers" boot param
> needs to be used to expose pointers during slub_debug reports.
>
> Cc: Vlastimil Babka <vbabka@...e.cz>
> Cc: Stephen Boyd <swboyd@...omium.org>
> Cc: concord@...too.org
> Cc: Pekka Enberg <penberg@...nel.org>
> Cc: David Rientjes <rientjes@...gle.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@....com>
> Cc: Petr Mladek <pmladek@...e.com>
> Cc: linux-mm@...ck.org
> Cc: stable@...r.kernel.org
> Link: https://lore.kernel.org/lkml/202109200726.2EFEDC5@keescook/
> Signed-off-by: Kees Cook <keescook@...omium.org>
in the commit message:
> Obscuring the pointers that slub shows when debugging makes for some
> confusing slub debug messages:
>
> Padding overwritten. 0x0000000079f0674a-0x000000000d4dce17
>
> Those addresses are hashed for kernel security reasons. If we're trying
> to be secure with slub_debug on the commandline we have some big
> problems given that we dump whole chunks of kernel memory to the kernel
> logs.
it dumps parts of kernel memory anyway and I'm not sure if slub_debug is
supposed to be used for security hardening.
what about introducing new boot parameter like, slub_hardening,
which does not print anything?
Powered by blists - more mailing lists