linux-kernel - Re: [PATCH] powerpc: Don't use %pK through printk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250226105757-e935ee3e-f70d-4e0e-83bb-61307722a186@linutronix.de>
Date: Wed, 26 Feb 2025 11:15:09 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Christophe Leroy <christophe.leroy@...roup.eu>, 
	Mahesh J Salgaonkar <mahesh@...ux.ibm.com>, Oliver O'Halloran <oohall@...il.com>, 
	Madhavan Srinivasan <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, 
	Nicholas Piggin <npiggin@...il.com>, Naveen N Rao <naveen@...nel.org>, linuxppc-dev@...ts.ozlabs.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] powerpc: Don't use %pK through printk

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