[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy58SHOCbJWtzB94PuT0d9UmdJ8QUZt+MjDYL9qbdfxbw@mail.gmail.com>
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.
