Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Oct 2017 21:58:24 +0000
From: "Roberts, William C" <>
To: Linus Torvalds <>, Jordan Glover
CC: "Tobin C. Harding" <>, 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

> -----Original Message-----
> From: [] On Behalf Of Linus
> Torvalds
> Sent: Wednesday, October 4, 2017 12:19 PM
> To: Jordan Glover <>
> Cc: Tobin C. Harding <>; Greg KH <>;
> Petr Mladek <>; Joe Perches <>; Ian
> Campbell <>; Sergey Senozhatsky
> <>;;
> Catalin Marinas <>; Will Deacon
> <>; Steven Rostedt <>; Roberts,
> William C <>; Chris Fries <>; Dave
> Weinstein <>
> Subject: Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter
> options
> On Wed, Oct 4, 2017 at 11:58 AM, Jordan Glover
> <> wrote:
> > If we knew where those leaks are hiding they will be fixed already.
> > The only thing we knew is that bugs/leaks are there. It's always
> > better to just fix all the code but it isn't realistic.
> Honestly, what's the difference between setting kptr_restrict to 4 and just using
> a sed-script (or maybe some coccinelle) to remove all existing plain %p users?

I can already see the hate filled irate response I'll get to this statement, thankfully I will
be away not caring.

The kernel proper is in a place where it can attempt to defend itself against stupidity, either in
tree or out of tree. Will it stop everything? Obviously not, like you said %x or disabling.

I agree with you 100% kptr restrict is odd, and I don't think anyone should have had to opt in to be
cleansed via kptr_restrict value via %pK. Opt-in never works. One nice thing now, is that checkpatch
has checking of %p usages and warns.
As far as broken things, I can't comment on desktop systems where I think it's harder to make that claim.
I see value in embedded systems where I am shipping the whole image, So I know when/what will

If this was in-tree, Android would be setting this to 4 immediately FWIW.

> One just hides the issue and will make people work around it (likely on a global
> level by just undoing it).
> The other would *also* make people work around it for when they notice
> breakage, but would actually force people to do it on a case-by-case basis (and
> thus hopefully _properly_) rather than just setting kptr_restrict back to 0.
> Btw, this is *not* a theoretical argument.
> kptr_restrict goes back to 6+ years ago, and was actually initially set to a
> restrictive value. It got undone, exactly because it caused problems. It's too big of
> a hammer, and it's too *broken* of a hammer.
> And exactly because kptr_restrict was pretty much an "all or nothing"
> thing, absolutely *NOTHING* has improved in the 6+ years since it was
> introduced.
> We have had improvements in our pointer printing that were _not_ related to
> kptr_restrict, though, See for example commit bb5e5ce545f2
> ("x86/dumpstack: Remove kernel text addresses from stack dump").
> Those have actually been _real_ fixes for leaking things, unlike kptr_restrict.
> This is why I maintain that kptr_restrict is bad. It's a badly thought out interface.
> It's wrong.
> We know it is crap, exactly because we've already been there. The whole notion
> of a global switch is seriously mis-designed.
> So I really do think that it would be better to just write a script to get rid of all raw
> %p users, and then put the ones that are needed (hopefully very few) back.
> It wouldn't require odd new magic sequences to override "I actually _do_ want
> %p".
>               Linus

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.