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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.