Date: Mon, 6 Nov 2017 09:27:09 -0800 From: Linus Torvalds <torvalds@...ux-foundation.org> To: "Tobin C. Harding" <me@...in.cc>, Network Development <netdev@...r.kernel.org>, David Miller <davem@...emloft.net> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, "Jason A. Donenfeld" <Jason@...c4.com>, "Theodore Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>, Paolo Bonzini <pbonzini@...hat.com>, Tycho Andersen <tycho@...ker.com>, "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>, Catalin Marinas <catalin.marinas@....com>, Will Deacon <wilal.deacon@....com>, Steven Rostedt <rostedt@...dmis.org>, Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>, Daniel Micay <danielmicay@...il.com>, Djalal Harouni <tixxdz@...il.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v3] scripts: add leaking_addresses.pl On Sun, Nov 5, 2017 at 9:19 PM, Tobin C. Harding <me@...in.cc> wrote: > Currently we are leaking addresses from the kernel to user space. This > script is an attempt to find some of those leakages. Script parses > `dmesg` output and /proc and /sys files for hex strings that look like > kernel addresses. Lovely. This is great. It shows just how much totally pointless stuff we leak, and to normal users that really shouldn't need it. I had planned to wait for 4.15 to look at the printk hashing stuff etc, but this part I think I could/should merge early just because I think a lot of kernel developers will go "Why the f*ck would we expose that kernel address there?" The module sections stuff etc should likely be obviously root-only, although maybe I'm missing some tool that ends up using it and is useful to normal developers. And I'm thinking we could make kallsyms smarter too, and instead of depending on kptr_restrict that screws over things with much too big a hammer, we could make it take 'perf_event_paranoid' into account. I suspect that's the main user of kallsyms that would still be relevant to non-root. I really really hate kptr_restrict due to that whole "all or nothing" thing. The networking code ends up having a ton of "sk" pointers, and I suspect those would all be fine just using the hashed address, since nobody is going to care about the _actual_ kernel address, but matching a socket reference in one file against another one makes tons of sense and I would not be surprised if there's a lot of netstat-like tools that do that. So the whole '%pK' thing is entirely useless for them, but the "hash %p values" should work fine. Adding netdev and David Miller explicitly to the cc, since many of the kernel pointer leaks are from them, and they may not even have been following this discussion at all. David - you can see the patch on patchwork: https://patchwork.kernel.org/patch/10042605/ and try it out yourself. I heartily recommend other developers run it too, just to see if it makes you go "Oh, I didn't even realize.." This looks much more interesting than the whole "%p vs %pK vs %x" discussion. 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.