All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Ke Sun <sunke@kylinos.cn>
Cc: "Dirk Behme" <dirk.behme@gmail.com>,
	"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Petr Mladek" <pmladek@suse.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Timur Tabi" <ttabi@nvidia.com>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Benno Lossin" <lossin@kernel.org>,
	"John Ogness" <john.ogness@linutronix.de>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Tamir Duberstein" <tamird@gmail.com>,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v7 1/4] lib/vsprintf: Export functions for Rust pointer formatting support
Date: Wed, 31 Dec 2025 11:07:27 +0000	[thread overview]
Message-ID: <aVUD76o8dBVJpNVM@google.com> (raw)
In-Reply-To: <CALpAb9MoT20Ch4pe-oMz8kpqaZsvmgNwPk1XSC+faZi7huwQKg@mail.gmail.com>

On Wed, Dec 31, 2025 at 10:46:37AM +0800, Ke Sun wrote:
> On Mon, Dec 29, 2025 at 6:44 PM Dirk Behme <dirk.behme@gmail.com> wrote:
> >
> > On 29.12.25 08:21, Ke Sun wrote:
> > > Export ptr_to_hashval() and extract kptr_restrict_value() to enable
> > > Rust code to use kernel pointer formatting functionality.
> > >
> > > - Export ptr_to_hashval() with EXPORT_SYMBOL_GPL for pointer hashing.
> > >   This function is used to hash kernel pointers before printing them,
> > >   preventing information leaks about kernel memory layout.
> > >
> > > - Extract kptr_restrict handling logic from restricted_pointer() into
> > >   a separate exported function kptr_restrict_value() that can be
> > >   reused by both restricted_pointer() (for %pK format specifier) and
> > >   Rust code.
> > >
> > > The kptr_restrict_value() function:
> > > - Returns 0, 1, or 2 to indicate the kptr_restrict sysctl value
> > > - Returns -1 for error case (IRQ context with kptr_restrict==1)
> > > - Modifies the pointer value through @pptr parameter when needed
> > >   (sets to NULL when access should be restricted)
> > >
> > > These functions are needed for the HashedPtr and RestrictedPtr wrapper
> > > types in rust/kernel/ptr.rs to provide safe pointer formatting that
> > > matches C kernel patterns.
> > >
> > > This refactoring:
> > > - Allows restricted_pointer() to reuse the common logic while
> > >   maintaining the same behavior
> > > - Enables Rust code to use the same kptr_restrict handling logic
> > > - Reduces code duplication
> > >
> > > Signed-off-by: Ke Sun <sunke@kylinos.cn>
> > > Suggested-by: Boqun Feng <boqun.feng@gmail.com>
> > > ---
> > >  include/linux/printk.h | 10 ++++++++
> > >  lib/vsprintf.c         | 55 ++++++++++++++++++++++++++++++++----------
> > >  2 files changed, 52 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/include/linux/printk.h b/include/linux/printk.h
> > > index 45c663124c9bd..91380b1eff1a1 100644
> > > --- a/include/linux/printk.h
> > > +++ b/include/linux/printk.h
> > > @@ -385,6 +385,16 @@ extern void __printk_cpu_sync_put(void);
> > >
> > >  extern int kptr_restrict;
> > >
> > > +/**
> > > + * kptr_restrict_value - Determine what pointer value should be used for %pK
> > > + * @pptr: Pointer to the pointer value (may be modified)
> > > + *
> > > + * Returns:
> > > + *   - 0, 1, or 2: The kptr_restrict value if pointer should be used
> > > + *   - -1: Error case (IRQ context with kptr_restrict==1), *pptr unchanged
> > > + */
> > > +int kptr_restrict_value(const void **pptr);
> > > +
> > >  /**
> > >   * pr_fmt - used by the pr_*() macros to generate the printk format string
> > >   * @fmt: format string passed from a pr_*() macro
> > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> > > index a3790c43a0aba..29d2e681c6e73 100644
> > > --- a/lib/vsprintf.c
> > > +++ b/lib/vsprintf.c
> > > @@ -811,6 +811,7 @@ int ptr_to_hashval(const void *ptr, unsigned long *hashval_out)
> > >  {
> > >       return __ptr_to_hashval(ptr, hashval_out);
> > >  }
> > > +EXPORT_SYMBOL_GPL(ptr_to_hashval);
> > >
> > >  static char *ptr_to_id(char *buf, char *end, const void *ptr,
> > >                      struct printf_spec spec)
> > > @@ -857,14 +858,28 @@ static char *default_pointer(char *buf, char *end, const void *ptr,
> > >
> > >  int kptr_restrict __read_mostly;
> > >
> > > -static noinline_for_stack
> > > -char *restricted_pointer(char *buf, char *end, const void *ptr,
> > > -                      struct printf_spec spec)
> > > +/**
> > > + * kptr_restrict_value - Determine what pointer value should be used for %pK
> > > + * @pptr: Pointer to the pointer value (may be modified)
> > > + *
> > > + * This function determines what pointer value should be printed based on the
> > > + * kptr_restrict sysctl setting:
> > > + *
> > > + * - kptr_restrict == 0: Return 0 (use original pointer, will be hashed)
> > > + * - kptr_restrict == 1: Return 1 if current process has CAP_SYSLOG and same
> > > + *                       euid/egid, otherwise set *pptr to NULL and return 1
> > > + * - kptr_restrict >= 2: Set *pptr to NULL and return 2
> > > + *
> > > + * Returns:
> > > + *   - 0, 1, or 2: The kptr_restrict value if pointer should be used
> > > + *   - -1: Error case (IRQ context with kptr_restrict==1), *pptr unchanged
> > > + */
> > > +int kptr_restrict_value(const void **pptr)
> >
> > Would it be an improvment to not modify the pptr itself? But instead
> > to work with some kind of in ptr (not modified) and out_ptr (returned
> > to the caller then)?
> >
> > kptr_restrict_value(const void *ptr, const void **out_ptr)
> >
> > And an enum for the result? With something like
> >
> > enum kptr_restict_result {
> >   KPTR_RESTICT_ERROR = -1,
> >   KPTR_RESTICT_NONE = 0,
> >   KPTR_RESTICT_PARTIAL = 1,
> >   KPTR_RESTICT_FULL = 2,
> > }
> >
> > What would result in something like
> >
> > enum kptr_restict_result kptr_restrict_value(const void *ptr, const
> > void **out_ptr)
> >
> > Opinions?
> 
> Given that fully implementing all %p format specifier extensions would
> require substantial code changes, we're considering converting Rust's
> Formatter to C format strings at the Rust layer and directly calling
> snprintf. This would allow us to reuse the existing C implementations
> without modifying vsprintf.c.
> 
> What do you think of this approach?

That's never going to happen. It would be quite difficult to write a
safe API where you can't accidentally mix up the wrong type with the C
format string. You would probably have to write a proc macro parser for
format strings, which sounds like a nightmare. And you will never be
able to get error messages that are as good as the built-in formatting
machinery, because it relies on compiler internals and cannot be
reproduced in a custom proc macro.

I think Dirk's suggestion is reasonable. Or just do not support %pK.

Alice

  reply	other threads:[~2025-12-31 11:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-29  7:21 [PATCH v7 0/4] rust: Add safe pointer formatting support Ke Sun
2025-12-29  7:21 ` [PATCH v7 1/4] lib/vsprintf: Export functions for Rust " Ke Sun
2025-12-29 10:44   ` Dirk Behme
2025-12-31  2:46     ` Ke Sun
2025-12-31 11:07       ` Alice Ryhl [this message]
2025-12-29 14:18   ` Andy Shevchenko
2025-12-29 15:00     ` Ke Sun
2025-12-31 10:04     ` Alice Ryhl
2026-01-01  1:43       ` 孙科
2026-01-01  1:46         ` Alice Ryhl
2025-12-29  7:21 ` [PATCH v7 2/4] rust: kernel: Add pointer wrapper types for safe pointer formatting Ke Sun
2025-12-29  9:03   ` Alice Ryhl
2025-12-29 14:07     ` Ke Sun
2025-12-29  7:21 ` [PATCH v7 3/4] rust: fmt: Default raw pointer formatting to HashedPtr Ke Sun
2025-12-29  7:21 ` [PATCH v7 4/4] docs: rust: Add pointer formatting documentation Ke Sun
2025-12-29 14:11 ` [PATCH v7 0/4] rust: Add safe pointer formatting support Andy Shevchenko
2025-12-30  2:03   ` Ke Sun
2025-12-30  8:40     ` Andy Shevchenko

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=aVUD76o8dBVJpNVM@google.com \
    --to=aliceryhl@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dirk.behme@gmail.com \
    --cc=gary@garyguo.net \
    --cc=john.ogness@linutronix.de \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=sunke@kylinos.cn \
    --cc=tamird@gmail.com \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.