[PATCH] powerpc: Don't use %pK through printk

[Thomas Weißschuh]

On Tue, Feb 25, 2025 at 05:32:12PM +0000, Maciej W. Rozycki wrote:
> On Tue, 25 Feb 2025, Thomas Weißschuh wrote:
> 
> > > was suddenly lost from the kernel log, the access to which unprivileged 
> > > users can be denied if so desired according to the site policy.  Whereas 
> > > running the kernel such as to have all output from plain `%p' exposed just 
> > > to cope with this proposed change, now that seems like a security risk.
> > 
> > Your point makes sense.
> > *But* the addresses in your example are already hashed,
> > as indicated by the all-zero upper 32 bits.
> 
>  Darn it!

Agreed.

> > By default, when kptr_restrict is set to 0, %pK behaves the same as %p.
> > The same happened for a bunch of other architectures and nobody seems
> > to have noticed in the past.
> > The symbol-relative pointers or pointer formats designed for backtraces,
> > as notes by Christophe, seem to be enough.
> 
>  I do hope so.

As mentioned before, personally I am fine with using %px here.
The values are in the register dumps anyways and security sensitive deployments
will panic on WARN(), making the information disclosure useless.

> > But personally I'm also fine with using %px, as my goal is to remove the
> > error-prone and confusing %pK.
> 
>  It's clear that `%pK' was meant to restrict access to /proc files and the 
> like that may be accessible by unprivileged users:

Then let's stop abusing it. For something that is clear, it is
misunderstood very often.

> "
> kptr_restrict
> =============
> 
> This toggle indicates whether restrictions are placed on
> exposing kernel addresses via ``/proc`` and other interfaces.
> "
> 
> and not the kernel log, the information in which may come from rare events 
> that are difficult to trigger and hard to recover via other means.  Sigh. 
> Once you've got access to the kernel log, you may as well wipe the system 
> or do any other harm you might like.

As I understand it, both the security and printk maintainers don't want the
kernel log in general to be security sensitive and restricted.
My goal here is not to push site-specific policy into the kernel but make life
easier for kernel developers by removing the confusing and error-prone %pK
altogether.
Security is only one aspect.


Thomas