Date: Fri, 13 Oct 2017 12:34:30 -0700 From: Kees Cook <keescook@...omium.org> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: "Roberts, William C" <william.c.roberts@...el.com>, "Theodore Ts'o" <tytso@....edu>, "Tobin C. Harding" <me@...in.cc>, Tejun Heo <tj@...nel.org>, Jordan Glover <Golden_Miller83@...tonmail.ch>, 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 On Fri, Oct 13, 2017 at 11:11 AM, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Fri, Oct 13, 2017 at 9:32 AM, Roberts, William C > <william.c.roberts@...el.com> 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 -- 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.