[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Oct 2017 17:09:33 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Roberts, William C" <william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>
Cc: Jordan Glover <Golden_Miller83@...tonmail.ch>, "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
On Wed, Oct 4, 2017 at 4:52 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> It also shows
>
> software IO TLB [mem PA-PB] (64MB) mapped at [VA-VB]
>
> for example. And THIS IS IMPORTANT! The physical address is shown
> with "%#010llx".
Oh, and I added Tejun for the percpu printout, but didn't add Bjorn
for this one.
Like the percpu one, I suspect that this pr_info() isn't really
important enough to stay, and while it doesn't sound nearly as
interesting as the percpu virtual address to an attacker, it probably
isn't important enough to leak kernel (and hardware) data for.
Bjorn?
I suspect we could try to make people aware of these kinds of things.
The nice zero-day robots etc probably aren't wondeful for this (since
they'll have fairly limited hardware), but maybe we could have a
script that makes it easy to just say
"does dmesg seem to contain interesting numbers that really shouldn't
be leaked?"
That "egrep 'ffff[0-9a-f]{12}" is certainly not very good - not only
is it 64-bit specific, but it triggers, for example, on a "mask:
0xffffffffffffffff" from the clocksource code. But Something
*slightly* smarter could be something we could probably encourage
people to run occasionally.
... and if nothing else, maybe it makes developers more aware of the
"I shouldn't be leaking kernel data in dmesg" issue in general.
More so than just special-casing %p handling in odd ways and ignoring
all the other ways we can leak.
For example: x86 removed the raw stack dump last year (commit
0ee1dd9f5e7e: "x86/dumpstack: Remove raw stack dump"), because we
decided that triggering a BUG_ON() obviously does need to expose some
kernel data, but the stack wasn't worth it (and definitely tends to
contain nasty information). ARM has not (see "dump_mem()". Again,
that's not using %p. It uses to use %lx.
So is %p really the problem?
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.
