On Tue, Aug 12, 2025 at 10:34 PM Thomas Weißschuh
<thomas.weissschuh@xxxxxxxxxxxxx> wrote:
>
> On Tue, Aug 12, 2025 at 03:19:45PM -0700, Andrii Nakryiko wrote:
> > On Mon, Aug 11, 2025 at 5:08 AM Thomas Weißschuh
> > <thomas.weissschuh@xxxxxxxxxxxxx> wrote:
> > >
> > > In the past %pK was preferable to %p as it would not leak raw pointer
> > > values into the kernel log.
> > > Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
> > > the regular %p has been improved to avoid this issue.
> > > Furthermore, restricted pointers ("%pK") were never meant to be used
> > > through printk(). They can still unintentionally leak raw pointers or
> > > acquire sleeping locks in atomic contexts.
> > >
> > > Switch to the regular pointer formatting which is safer and
> > > easier to reason about.
> > >
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> > > ---
> > > include/linux/filter.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/filter.h b/include/linux/filter.h
> > > index 1e7fd3ee759e07534eee7d8b48cffa1dfea056fb..52fecb7a1fe36d233328aabbe5eadcbd7e07cc5a 100644
> > > --- a/include/linux/filter.h
> > > +++ b/include/linux/filter.h
> > > @@ -1296,7 +1296,7 @@ void bpf_jit_prog_release_other(struct bpf_prog *fp, struct bpf_prog *fp_other);
> > > static inline void bpf_jit_dump(unsigned int flen, unsigned int proglen,
> > > u32 pass, void *image)
> > > {
> > > - pr_err("flen=%u proglen=%u pass=%u image=%pK from=%s pid=%d\n", flen,
> > > + pr_err("flen=%u proglen=%u pass=%u image=%p from=%s pid=%d\n", flen,
> > > proglen, pass, image, current->comm, task_pid_nr(current));
> >
> > this particular printk won't ever be called from atomic context, so I
> > don't think the leak from atomic context matters much here. On the
> > other hand, %pK behavior is controlled by kptr_restrict and that might
> > be useful for debugging, so not sure there is much of a benefit to
> > switching to always obfuscated %p? Or am I missing something else
> > here?
>
> As %pK is so easy to abuse and the breakage is very non-obvious, I want to
> rework it to enforce its usage from "file context".
> For that, the printk users need to be gone first.
> For debugging, there is still "no_hash_pointers".
>
> How would the image pointer be used for debugging?
I chatted with Daniel about this offline, and it seems like this is
not that critical nowadays. So I went ahead and applied the patch to
bpf-next.
> It is logged from nowhere else.
> And the raw image is dumped right after anyways.
>
> >
> > >
> > > if (image)
> > >
> > > ---
> > > base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585
> > > change-id: 20250811-restricted-pointers-bpf-04da04ea1b8a
> > >
> > > Best regards,
> > > --
> > > Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> > >
