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 13:47:07 -0700
From: Kees Cook <>
To: Linus Torvalds <>
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:22 PM, Linus Torvalds
<> wrote:
> I'm acknowledging that it's a complete hack that may have made sense
> in a particular setting, but it's not one that actually fixes any real
> security issues, and in particular, it's one that has likely held
> people back from doing *real* security.
> And as a maintainer of the kernel, to me that "long term actual
> development" is a whole lot more important than "silly hack that might
> close a random escape or two".
> So yes, I'm actually opposed to the global flag, because we seriously
> have 6+ years of reality staring us in the face: it fixed exactly
> nothing. It fixed /proc/kallsyms,m but did so _badly_. It fixed a
> handful of other places. But it didn't really and truly add any real
> security.
> Are people really in denial about this? Really?

I totally agree that %pK isn't actually useful. (I think of %pK and a
global flag controlling %p behavior as separate things.) The original
patch I was talking about fully acknowledges this (%pK not actually
working) and was about changing %p behavior. Some other solution was
needed that didn't drive developers into using %x for everything

> The whole "let's make %p print a hashed address" is not the real
> security part. That's just the "make it easy to do something secure by
> _default_" part. The real security is actually scanning for bad
> things, not profiling the escape sequences.

So yes, it's trivial to scan for stuff in dmesg, but it's much less
trivial to find the cases where some /proc entry only has %p reports
under certain runtime conditions. (e.g. print the allocation address
of a pending wifi association timer or something: visible only during
a brief window, and something not obvious to a casual scan of /proc
entry contents, but an attacker might be able to influence and peek

I'm also fine with eliminating the use of %p in source, but that's a
serious game of whack-a-mole, and I don't think it scales. So, yeah,
while I do like the %p-hash idea, I remain concerned that we'll just
have this whole discussion again in a few years, trying to figure out
what to do about the now heavily-used %x.

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 (

Can we do something more about %x?

Do we want to remove %pK also?


Kees Cook
Pixel Security

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.