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