Date: Wed, 11 Oct 2017 09:49:56 -0700 From: Linus Torvalds <torvalds@...ux-foundation.org> To: "Tobin C. Harding" <me@...in.cc> Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, KVM list <kvm@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 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 <will.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> Subject: Re: [PATCH] printk: hash addresses printed with %p On Tue, Oct 10, 2017 at 8:48 PM, Tobin C. Harding <me@...in.cc> wrote: > > Add function ptr_to_id() to map an address to a unique identifier. This > mapping is created by calling ptr_obfuscate() to hash the address. The > hashing algorithm is carried out in two stages. First the address is > xor'd by a random value then we multiply the xor production by a second > random value. So that's a fine obfuscation for normal kernel addresses. It's also fine for testing this feature, and forcing people who actually care about the real pointer value to look at thei rcode. However, it's almost certainly no good for hardening. The reasons is that it's going to be fairly trivial to just reverse the obfuscation if you have any kind of pattern to the pointers printed out. And there's tons of information like that. Some code (think KASAN reports etc) might print out addresses that increment with a fixed offset. In other situations, NULL is going to be fairly common. In yet other cases, you'll know specific bit patterns of the pointers (like "I know this reports a page address, so the upper 14 bits are all set, and the lower 12 bits are all zero"). You need just a few of those kinds of things, and you're going to easily break the obfuscation. A *normal* user won't bother. A kernel developer won't bother. But somebody writing an attack would. It's an inconvenience, and maybe it would push somebody towards an easier attack if one can be found, but it's not really a particularly _big_ inconvenience. So I'm absolutely ok with this patch for testing, and for finding the places that need fixing up, but it should be clear that for real hardening we'd need something much smarter. 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.