Date: Tue, 12 Dec 2017 16:26:02 +1100 From: Michael Ellerman <mpe@...erman.id.au> To: Linus Torvalds <torvalds@...ux-foundation.org>, Andy Shevchenko <andy.shevchenko@...il.com>, Kees Cook <keescook@...omium.org> Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, David Laight <David.Laight@...lab.com>, "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>, "mingo\@kernel.org" <mingo@...nel.org>, "jiangshanlai\@gmail.com" <jiangshanlai@...il.com>, "dipankar\@in.ibm.com" <dipankar@...ibm.com>, "akpm\@linux-foundation.org" <akpm@...ux-foundation.org>, "mathieu.desnoyers\@efficios.com" <mathieu.desnoyers@...icios.com>, "josh\@joshtriplett.org" <josh@...htriplett.org>, "tglx\@linutronix.de" <tglx@...utronix.de>, "peterz\@infradead.org" <peterz@...radead.org>, "rostedt\@goodmis.org" <rostedt@...dmis.org>, "dhowells\@redhat.com" <dhowells@...hat.com>, "edumazet\@google.com" <edumazet@...gle.com>, "fweisbec\@gmail.com" <fweisbec@...il.com>, "oleg\@redhat.com" <oleg@...hat.com>, kernel-hardening@...ts.openwall.com <kernel-hardening@...ts.openwall.com>, "Tobin C. Harding" <me@...in.cc> Subject: Long live %pK (was Re: [PATCH tip/core/rcu 02/20] torture: Prepare scripting for shift from %p to %pK) Linus Torvalds <torvalds@...ux-foundation.org> writes: > On Sun, Dec 10, 2017 at 4:52 AM, Andy Shevchenko > <andy.shevchenko@...il.com> 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? cheers
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.