Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Dec 2017 16:26:02 +1100
From: Michael Ellerman <>
To: Linus Torvalds <>, Andy Shevchenko <>, Kees Cook <>
Cc: "Paul E. McKenney" <>, David Laight <>, "linux-kernel\" <>, "mingo\" <>, "jiangshanlai\" <>, "dipankar\" <>, "akpm\" <>, "mathieu.desnoyers\" <>, "josh\" <>, "tglx\" <>, "peterz\" <>, "rostedt\" <>, "dhowells\" <>, "edumazet\" <>, "fweisbec\" <>, "oleg\" <>, <>, "Tobin C. Harding"  <>
Subject: Long live %pK (was Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK)

Linus Torvalds <> writes:
> On Sun, Dec 10, 2017 at 4:52 AM, Andy Shevchenko
> <> wrote:
>>>> Perhaps it should have printed a fixed, non-zero value for non-zero
>>>> pointers.
>>> I must leave this to the people who have a dog in that contest.  ;-)
>> Since there is an ongoing discussion with security people near to %pK
>> and alike, I added Kees and Linus to Cc list.
>> The proposed change can be done easily, though I have no knowledge
>> about possible implications.
> I'd rather make %pK act more like %p than have gratuitous differences.

But %pK has one crucial feature that %p does not, which is that %pK can
actually show the real value.

> I also think %pK is kind of pointless in general. It has not been a
> big success, and the whole "root or not" is kind of nasty anyway. Root
> in a container? Things like that.

At least with docker, root in a container doesn't get CAP_SYSLOG by
default, and so %pK works perfectly.

That is, root in the container can't see %pK things, but root on the
host can.

So consider /proc/vmallocinfo:

> So I think that if people worry  about leaking pointers, they should
> primarily go for:
>  - just use %p and now get the hashed value

Hopefully we can agree that the hashed value is not very useful when
you're looking at vmallocinfo. You're almost always trying to determine
if a value from an oops or elsewhere is contained within one of the
mappings, and for that you need to know the address ranges.

>  - if the hashed value is pointless, ask yourself whether the pointer
> itself is important. Maybe it should be removed?

A real bug we hit yesterday, a bad page fault in a *guest* that appears
to be trying to dereference a vmalloc address from the *host* (obviously
that should not happen). First step in debugging is to check if the
address lies within a valid mapping in /proc/vmallocinfo on the host. To
do that you need the pointers.

>  - as a last option, if you really  think the true pointer value is
> important, why is root so special, and maybe you should use %px and
> make sure you have proper sensible permissions.

/proc/vmallocinfo is already 0400.

But we definitely do not want to use %px for vmallocinfo, because that
would expose the values to root in containers.

> ..and %pK just isn't really the answer in any of those cases.

So in this case it seems %pK is a better answer than %p or %px.

I understand that the CAP_SYSLOG checking that %pK does is kind of
gross, but it does work in at least some useful cases like this.

What am I missing?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.