[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
