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.