Date: Fri, 13 Oct 2017 11:11:49 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: "Roberts, William C" <william.c.roberts@...el.com> Cc: "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 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). > Another possible solution discussed would be to enable an option to encrypt dmesg. But I > steered away from that. Yeah, that would make it really hard for bug reporters. And as discussed, it's not _just_ about dmesg, since %p shows up elsewhere too. That said, it *might* make sense to restrict dmesg, and have actual hard limits on message levels. Many (most?) of the %p users that intentionally expose kernel and hardware addresses are about debug messages. Often they are disabled entirely anyway, but it might make sense to just limit the dmesg output to "information and above" to regular users. But practically speaking, you end up traditionally having the system logs visible other ways (ie /var/log/messages or journalctl) that would make that kind of limiting pointless. So I think we're practically speaking limited to just trying to avoid printing sensitive information. And for all the historical baggage reasons, I do think we effectively just need to make it do so by default, with an opt-out for people who have good reason to do so, because '%pK' obviously didn't really end up working. (We _do_ have some %pK in the driver code that has grown up over the last 6+ years, but they are a small minority, and most of them are actually fundamentally broken with kptr_restrict=1, and only work with the values of 0 or 2+) > 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. 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.