Quoting Kees Cook (2021-09-20 11:28:50)

On Mon, Sep 20, 2021 at 11:23:01AM -0700, Stephen Boyd wrote:

quoted

Quoting Kees Cook (2021-09-20 07:29:54)

quoted

On Tue, Jun 01, 2021 at 11:22:02AM -0700, Stephen Boyd wrote:

quoted

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. Let's force on the no_hash_pointers commandline flag when
slub_debug is on the commandline. This makes slub debug messages more
meaningful and if by chance a kernel address is in some slub debug
object dump we will have a better chance of figuring out what went
wrong.

Note that we don't use %px in the slub code because we want to reduce
the number of places that %px is used in the kernel. This also nicely
prints a big fat warning at kernel boot if slub_debug is on the
commandline so that we know that this kernel shouldn't be used on
production systems.

Eeeek. I missed this patch. NAK NAK. People use slub_debug for
production systems to gain redzoning, etc, as a layer of defense, and
they absolutely do not want %p-hashing disabled. %p hashing is
controlled by the no_hash_pointers boot param (since v5.12), and needs to stay
separate from slub_debug.

Can we please revert this in Linus's tree and in v5.14?

This is fine with me as long as debugging with slub_debug on the
commandline is possible. Would you prefer v1 of this patch series[1]
that uses the printk format to print unhashed pointers in slub debugging
messages?

[1] https://lore.kernel.org/r/20210520013539.3733631-1-swboyd@chromium.org (local)

I'd like to keep %px use in the kernel minimized. Seeing full pointers (%p
hashing disabled) can be done with the no_hash_pointers boot param, and
that's used in other debug cases as well. I'd rather keep it a global
knob.

Can you elaborate on your use case where slub debugging is used for
security in production systems via redzoning? Maybe that redzoning logic
in slub debug should be moved out of CONFIG_SLUB_DEBUG into slub proper?
Or maybe the config symbol should be changed to something that doesn't
have 'debug' in the name?

The main goal of this series was to make slub debug messages I saw
useful instead of confusing given that all the pointers were hashed. If
some part of slub debugging is production critical then I wonder why
it's behind a debug named config knob and why it prints so much pointer
information on production systems.