Linux Hardening
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Kees Cook <kees@kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Tycho Andersen <tycho@tycho.pizza>
Subject: Re: [PATCH v2 1/2] vsprintf: Don't leak pointers for %ps without KALLSYMS enabled
Date: Mon, 31 Aug 2026 16:22:35 +0200	[thread overview]
Message-ID: <apWOKw7uqM_4R-C3@pathway.suse.cz> (raw)
In-Reply-To: <20260831133021.PtgflU-O@linutronix.de>

On Mon 2026-08-31 15:30:21, Sebastian Andrzej Siewior wrote:
> On 2026-08-27 11:51:00 [+0200], Petr Mladek wrote:
> > 
> > I think that it is a matter of taste. I could understand that
> > "(unknown)" might look more obvious to some people.
> > 
> > I would still prefer the hashed pointer. It make it consistent with
> > %p handling. Both print addresses in this case.
> 
> For %p expect a pointer, for %pS you expect a name.
> 
> > The motivation for the hash in %p is that it is slightly more useful
> > than a static string, e.g. "(address)" or "(pointer)". The hash allows
> > to match the same addresses. It is not 100% reliable but better
> > than nothing.
> 
> but is this helpful?
> 
> > Also the hash makes it more obvious the connection with "no_hash_pointer"
> > option.
> 
> Assuming you know about the no_hash_pointer. And then you get a
> randomized pointer. Enabling kallsym would be a _bigger_ help than
> rebooting with no_hash_pointer.
> 
> > IMHO, the only drawback is that people might confuse the hash with
> > a real value. But it is easier on 64-bit systems because the higher
> > 32-bits are zeros.
> 
> That, too. Do you continue to insist on this hashed pointer output here?

I do not insist on it. IMHO, this does not have a good solution.
I wish we got feedback from more people.

Let's give it few more days. The merge window has just ended.
People might have more time to go through pending mails.

Best Regards,
Petr

  reply	other threads:[~2026-08-31 14:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-21 15:26 [PATCH v2 0/2] vsprintf: Don't leak pointers Sebastian Andrzej Siewior
2026-08-21 15:26 ` [PATCH v2 1/2] vsprintf: Don't leak pointers for %ps without KALLSYMS enabled Sebastian Andrzej Siewior
2026-08-26 15:56   ` Petr Mladek
2026-08-27  9:14     ` Sebastian Andrzej Siewior
2026-08-27  9:51       ` Petr Mladek
2026-08-31 13:30         ` Sebastian Andrzej Siewior
2026-08-31 14:22           ` Petr Mladek [this message]
2026-08-21 15:26 ` [PATCH v2 2/2] kallsyms: Document why unresolved symbols are revealed Sebastian Andrzej Siewior
2026-08-26 16:21   ` Petr Mladek
2026-08-27 10:24     ` Sebastian Andrzej Siewior
2026-08-31 13:37       ` Sebastian Andrzej Siewior
2026-08-31 16:49         ` Steven Rostedt
2026-09-01  7:23           ` Petr Mladek
2026-09-01  8:01             ` Sebastian Andrzej Siewior
2026-09-01 13:30               ` Steven Rostedt

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=apWOKw7uqM_4R-C3@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tycho@tycho.pizza \
    /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