Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy2CQ_AFahTQynumDL6ocZD5R23v=HXLYS6w_E1tpY-1Q@mail.gmail.com>
Date: Sat, 7 Oct 2017 17:08:29 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Theodore Ts'o" <tytso@....edu>
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 Sat, Oct 7, 2017 at 4:44 PM, Theodore Ts'o <tytso@....edu> wrote:
>
> 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.

I doubt it's going to be used enough to be worth it.

So I'd rather just make it a hash that gives you that identity for
people who want it, and then people who actually need the address
would need to decide whether they _really_ need it in the first place,
or whether they would use %lx instead together with stricty security
rules.

I did test the patch I sent out (using jhash - so not a cryptographic
hash, and with a "random value" that was just a constant) just to see
that it doesn't break anything obvious. As expected, it did break
kernel profiling (which uses /proc/kallsyms), and it obviously made
the kernel pointers I'd already found in dmesg be just garbage, but it
didn't seem insurmountable. More like a "with a couple of fixup cases,
it might all work fine".

So I'd be willing to try it for the next merge window, and see if it
causes unexpected problems..

                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.