Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ