Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 13 Oct 2017 16:32:40 +0000
From: "Roberts, William C" <>
To: Linus Torvalds <>, Theodore Ts'o
CC: "Tobin C. Harding" <>, Tejun Heo <>, Jordan Glover
	<>, Greg KH <>, "Petr
 Mladek" <>, Joe Perches <>, Ian Campbell
	<>, Sergey Senozhatsky <>,
	"" <>,
	Catalin Marinas <>, Will Deacon <>,
	Steven Rostedt <>, Chris Fries <>, "Dave
 Weinstein" <>
Subject: RE: [RFC V2 0/6] add more kernel pointer filter

> -----Original Message-----
> From: [] On Behalf Of Linus
> Torvalds
> Sent: Saturday, October 7, 2017 5:08 PM
> To: Theodore Ts'o <>
> Cc: Roberts, William C <>; Tobin C. Harding
> <>; Tejun Heo <>; Jordan Glover
> <>; Greg KH <>;
> Petr Mladek <>; Joe Perches <>; Ian
> Campbell <>; Sergey Senozhatsky
> <>;;
> Catalin Marinas <>; Will Deacon
> <>; Steven Rostedt <>; Chris Fries
> <>; Dave Weinstein <>
> 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 <> 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.