Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Oct 2017 14:45:38 -0700
From: Linus Torvalds <>
To: Kees Cook <>
Cc: "Roberts, William C" <>, "Theodore Ts'o" <>, 
	"Tobin C. Harding" <>, Tejun Heo <>, 
	Jordan Glover <>, Greg KH <>, 
	Petr Mladek <>, Joe Perches <>, Ian Campbell <>, 
	Sergey Senozhatsky <>, 
	"" <>, 
	Catalin Marinas <>, Will Deacon <>, 
	Steven Rostedt <>, Chris Fries <>, 
	Dave Weinstein <>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter options

On Fri, Oct 13, 2017 at 1:47 PM, Kees Cook <> wrote:
> Is the correct path to:
> - unconditionally convert %p to reporting a 32-bit hash
> - actively start removing as much %p use as possible
> - do something to discourage %x on pointers (

I don't know if we even need to remove %p if we just unconditionally hash it.

I _think_ that what will happen if we just start hashing %p is that
99% of existing %p cases will just stay around, because many of them
are likely effectively stale. Maybe they were useful for driver
development, but they probably aren't any more.

The 1% that will cause people to look at the code may well be painful,
though. We are potentially talking more than just a handful here.

We *may* actually want to introduce %pX as a way to opt _out_ of the
hashing, so that  %p users that really do want an address can keep it
- while making it  really easy to grep for (and then maybe
kptr_restrict=4 would say "even %pX gets hashed anyway").

As to %x and pointers, I'm not sure how to do that with checkpatch.
And I don't even think it's about pointers. If people care about the
physical addresses leaking (and the %pa format kind of indicates
people do), the most common physical addresses likely are %x printouts
before those addresses were made into pointers at all. Those physical
addresses often came from somewhere else where they were just integers
(eg PCI BAR values etc).

So realistically, that's where the "let's try to come up with scripts
to find those things" comes in.

... and just perhaps generally talk about this "don't leak pointers or
physical addresses to random user space" so that people are more aware
of it in general.

That, btw, might be a side effect of %p being hashed in the first
place. People will go "WTF?" for a while, and just _explaining_ the %p
hashing might make people more aware of this issue in the first place.

Or maybe I'm just unrealistically optimistic, and what will _actually_
happen if we start hashing %p output is just a lot and lot of
complaining and whining and tons of breakage. ;(

> Can we do something more about %x?
> Do we want to remove %pK also?

I'm not sure we need to. But there may be %pK users that simply think
that getting a hashed address is better than getting just zeroes, and
that would thus prefer going back to %p.


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.