Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Oct 2017 19:44:53 -0400
From: Theodore Ts'o <tytso@....edu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Roberts, William C" <william.c.roberts@...el.com>,
	"Tobin C. Harding" <me@...in.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>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter
 options

On Thu, Oct 05, 2017 at 09:19:17AM -0700, Linus Torvalds wrote:
>  - meaningful hardware addresses (ie the pointer is some mmio pointer).
> 
> At least the first case could possibly continue to use a '%p' that
> simply hashes the actual pointer value with some hash or something
> like that. It's not the pointer itself that is important, it's just
> the "identity" of the socket or device or whatever.
> 
> Of course, "just hash it" isn't good enough if we're just hiding the
> (very limited) kernel address space randomization, but mixing in a
> per-boot random value might be sufficient.

Maybe this is overkill, but what about *encrypting* the pointer using
fixed, per-boot random key?  It would have to be a block crypto
algorithm, like Tea/XXTea/XXTEA or Speck.  That has all of the
benefits of hashing, plus if the key is available (only to privileged
users, of course), then it would be possible to get the pointer for
debugging purposes.

						- Ted

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ