Date: Fri, 13 Oct 2017 16:32:40 +0000 From: "Roberts, William C" <william.c.roberts@...el.com> To: Linus Torvalds <torvalds@...ux-foundation.org>, Theodore Ts'o <tytso@....edu> CC: "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 > -----Original Message----- > From: linus971@...il.com [mailto:linus971@...il.com] On Behalf Of Linus > Torvalds > Sent: Saturday, October 7, 2017 5:08 PM > 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; > 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: [kernel-hardening] [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.. I don't particularly hate this idea, and I actually discussed this before with others (not on the list) before approaching it using kptr_restrict. The argument that we had against this approach was that it would push people away from using %p and make it even that much harder to audit. But, I'm not sure if that's really that valid or strong of an argument. I would say go for that approach with an timeline/agreement to kill kptr_restrict. Another possible solution discussed would be to enable an option to encrypt dmesg. But I steered away from that. I settled on using kptr_restrict for the ability to enable/disable. One of the use cases we had was that a driver is found to be doing this silly thing, and an admin/user wants to turn it off in dmesg until its fixed. > > 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.