[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC563EAF4F29@ORSMSX103.amr.corp.intel.com>
Date: Wed, 4 Oct 2017 21:58:24 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>, Jordan Glover
<Golden_Miller83@...tonmail.ch>
CC: "Tobin C. Harding" <me@...in.cc>, Greg KH <gregkh@...uxfoundation.org>,
Petr Mladek <pmladek@...e.com>, Joe Perches <joe@...ches.com>, Ian Campbell
<ijc@...lion.org.uk>, Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will.deacon@....com>,
Steven Rostedt <rostedt@...dmis.org>, Chris Fries <cfries@...gle.com>, "Dave
Weinstein" <olorin@...gle.com>
Subject: RE: [RFC V2 0/6] add more kernel pointer filter
options
> -----Original Message-----
> From: linus971@...il.com [mailto:linus971@...il.com] On Behalf Of Linus
> Torvalds
> Sent: Wednesday, October 4, 2017 12:19 PM
> To: Jordan Glover <Golden_Miller83@...tonmail.ch>
> Cc: Tobin C. Harding <me@...in.cc>; Greg KH <gregkh@...uxfoundation.org>;
> Petr Mladek <pmladek@...e.com>; Joe Perches <joe@...ches.com>; Ian
> Campbell <ijc@...lion.org.uk>; Sergey Senozhatsky
> <sergey.senozhatsky@...il.com>; kernel-hardening@...ts.openwall.com;
> Catalin Marinas <catalin.marinas@....com>; Will Deacon
> <will.deacon@....com>; Steven Rostedt <rostedt@...dmis.org>; Roberts,
> William C <william.c.roberts@...el.com>; Chris Fries <cfries@...gle.com>; Dave
> Weinstein <olorin@...gle.com>
> 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
> <Golden_Miller83@...tonmail.ch> 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
break.
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.
>
> WE HAVE BEEN HERE, DONE THIS!
>
> 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.
