[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <476DC76E7D1DF2438D32BFADF679FC563F4AF172@ORSMSX115.amr.corp.intel.com>
Date: Fri, 13 Oct 2017 16:14:43 +0000
From: "Roberts, William C" <william.c.roberts@...el.com>
To: "Tobin C. Harding" <me@...in.cc>, Linus Torvalds
<torvalds@...ux-foundation.org>
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>, Joe Perches <joe@...ches.com>
Subject: RE: [RFC V2 0/6] add more kernel pointer filter
options
> -----Original Message-----
> From: Tobin C. Harding [mailto:me@...in.cc]
> Sent: Wednesday, October 4, 2017 7:19 PM
> To: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Roberts, William C <william.c.roberts@...el.com>; 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; 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: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter
> options
>
> On Wed, Oct 04, 2017 at 04:52:58PM -0700, Linus Torvalds wrote:
> > 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".
>
> This sounds like just the job for an upcoming kernel hacker, with a lot of time and
> not much experience, to do something laborious that no one else wants to do
> and learn a bunch about the kernel.
>
> So what if we drop this patch set and
>
> 1. Find and fix every place in the kernel that leaks addresses.
> 2. Verify that checkpatch.pl warns for all potential future leakage.
FYI: This was done in commit 0b523769ebb by Joe Perches. Added to CC line.
> 2. Add a script to check dmesg output for future hardening.
>
> I'm super keen to work. I would have to get everyone to dump their
> ideas/demands onto me if we are to get this fixed fully.
>
> thanks,
> Tobin.
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.
