Re: [PATCH net-next 0/7] net: Don't use %pK through printk

[Thomas Weißschuh]

On Mon, Apr 14, 2025 at 11:44:24AM -0700, Brian Norris wrote:
> On Mon, Apr 14, 2025 at 10:26:01AM +0200, Thomas Weißschuh wrote:
> > Furthermore, restricted pointers ("%pK") were never meant to be used
> > through printk().
> 
> Is this really true? Documentation/admin-guide/sysctl/kernel.rst still
> has a section on kptr_restrict which talks about dmesg, CAP_SYSLOG, and
> %pK, which sounds like it's intended. But I'm not highly familiar with
> this space, so maybe I'm misreading something.

The wording about dmesg, etc was added in
commit 312b4e226951 ("vsprintf: check real user/group id for %pK").

Its commit message also notes:

    This is a only temporary solution to the issue.  The correct solution is
    to do the permission check at open() time on files, and to replace %pK
    with a function which checks the open() time permission.  %pK uses in
    printk should be removed since no sane permission check can be done, and
    instead protected by using dmesg_restrict.

Doing this is my goal. One of the later steps is to replace %pK completely.
Probably with a function similar to kallsyms_show_value().

> (I do see that commit a48849e2358e ("printk: clarify the documentation
> for plain pointer printing") updated
> Documentation/core-api/printk-formats.rst.)
> 
> In any case, even if the advice has changed, it seems (again, to an
> outsider) a bit much to say it was "never" meant to be used through
> printk().

IMO "never" is correct. Using %pK through printk() was only ever a bandaid to
get at least some of the security benefits of hashed pointers.


Thomas