Re: [kernel-hardening] [RFC V2 0/6] add more kernel pointer filter options

["Tobin C. Harding" <me@tobin.cc>]

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@intel.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.
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.