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 12:34:30 -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 11:11 AM, Linus Torvalds
<> wrote:
> On Fri, Oct 13, 2017 at 9:32 AM, Roberts, William C
> <> wrote:
>> I don't particularly hate this idea, and I actually discussed this before with others (not on the list)
>> before approaching it using kptr_restrict. The argument that we had against this approach was
>> that it would push people away from using %p and make it even that much harder to audit.
> So I think kptr_restrict was worth trying. I'm not saying it was a bad
> idea when it was introduced.
> It's just that it's six years later, we now have the knowledge that
> opt-in doesn't work for this (either), and that we should just admit
> that it didn't work very well.
> And even as a "failure", the global flag may well work fine for soem
> uses (ie Android), largely because hardly anybody actually _develops_
> using Android. So it may not have been a failure in that sense, and
> for all I know the Android use-case really sees it as a huge success
> (and extending on it there would have made sense).

That's precisely where this comes from: the original patches from
Tobin (and Greg) were trying to make this extension, based on the work
done in the Android kernels (which was based on work by William, etc).

>> I settled on using kptr_restrict for the ability to enable/disable. One of the use cases
>> we had was that a driver is found to be doing this silly thing, and an admin/user wants
>> to turn it off in dmesg until its fixed.
> Hopefully just making %p print out a hash will fix the silly things.

I'm unable to tell if you're universally opposed to a global flag, or
if you're acknowledging that it has use in certain environments.

I get the sense that unconditionally censoring (either through
omission or a hash) of %p will likely drive people to using %x, and
that'll be really hard to audit. (I suppose it'd be possible to build
a compiler plugin that would look for %x uses where the format
argument was cast from a pointer type, but it seems like it'd be best
to avoid even needing such things.)

Having a global flag for censorship of %p means the developer case can
be left unchanged (meaning less migration to %x). Or were you
suggesting a global flag that controls the censorship level (e.g.
something like "none", "hash", "all zero")?


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.