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
