[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwEZCT6=BCdmaNn5LGeU8g-2qi4OnM9MTOep3NOZVXjMg@mail.gmail.com>
Date: Wed, 4 Oct 2017 16:52:58 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Roberts, William C" <william.c.roberts@...el.com>, Tejun Heo <tj@...nel.org>
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 2:58 PM, Roberts, William C
<william.c.roberts@...el.com> wrote:
>
> I agree with you 100% kptr restrict is odd, and I don't think anyone should have had to opt in to be
> cleansed via kptr_restrict value via %pK. Opt-in never works. One nice thing now, is that checkpatch
> has checking of %p usages and warns.
Yeah, the checkpatch thing may help for future patches.
> As far as broken things, I can't comment on desktop systems where I think it's harder to make that claim.
> I see value in embedded systems where I am shipping the whole image, So I know when/what will
> break.
>
> If this was in-tree, Android would be setting this to 4 immediately FWIW.
Does android set it to 2 right now?
But even if it does, my point is that we've had this thing for 6+
years, and it really hasn't helped fix our code much at all.
In fact, I think the opposite is true. I think it *hurts*. It hurts
exactly because it's a hack, and it makes people not bother to fix the
real problems.
I think we'd be better off just fixing code.
One thing you can do today is just look through your 'dmesg' for what
looks like kernel addresses (if virtual addresses is what you're
interested in - obviously physical addresses will look different). On
x86-64, for example, something like this:
dmesg | egrep 'ffff[0-9a-f]{12}'
might be interesting to look at. It shows (for me) that we show the
percpu address mapping, for example. That certainly sounds interesting
to a potential attacker, and I suspect Tejun isn't really interested
in that information any more. Added to Cc.
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".
See what I'm saying? The kptr_restrict games are just that: games and
security theater. If you actually care about things like physical
addresses, you don't say "let's hide %pa". Because that's not how the
real world works. I found one case that would entirely have missed
with the very first trivial grep I did.
So I'm claiming that anybody who says "it's too hard to fix it for
real, let's just paper over it in vsprintf.c" is fundamentally going
to miss things like this. I agree that it might be painful to try to
figure out where the problems are, but somebody like google probably
has a lot of dmesg output, and it should not be that hard to do the
above kinds of "let's just see what leaks, and FIX it".
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.
