kernel-hardening - Re: [RFC V2 0/6] add more kernel pointer filter options

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171004105051.GE16685@eros>
Date: Wed, 4 Oct 2017 21:50:51 +1100
From: "Tobin C. Harding" <me@...in.cc>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: 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, linux-kernel@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	William Roberts <william.c.roberts@...el.com>,
	Chris Fries <cfries@...gle.com>, Dave Weinstein <olorin@...gle.com>
Subject: Re: [RFC V2 0/6] add more kernel pointer filter
 options

On Wed, Oct 04, 2017 at 10:58:50AM +0200, Greg KH wrote:
> On Sun, Oct 01, 2017 at 11:06:44AM +1100, Tobin C. Harding wrote:
> > Version 2 of Greg's patch series with changes made as suggested by comments to V1.
> > 
> > Applies on top of Linus' current development tree
> > 
> > a8c964eacb21288b2dbfa9d80cee5968a3b8fb21
> > 
> > V1 cover letter:
> > 
> > Here's a short patch series from Chris Fries and Dave Weinstein that
> > implements some new restrictions when printing out kernel pointers, as
> > well as the ability to whitelist kernel pointers where needed.
> > 
> > These patches are based on work from William Roberts, and also are
> > inspired by grsecurity's %pP to specifically whitelist a kernel pointer,
> > where it is always needed, like the last patch in the series shows, in
> > the UIO drivers (UIO requires that you know the address, it's a hardware
> > address, nothing wrong with seeing that...)
> > 
> > I haven't done much to this patch series, only forward porting it from
> > an older kernel release (4.4) and a few minor tweaks. [snip]
> 
> Nice!  Thanks for doing this work, looks great to me.  Care to resend
> the next version as a "real" one (i.e. no RFC)?

First thing tomorrow!

Is correct protocol for me to add your Signed-off-by tag to each patch from this RFC? Or is the
protocol for you to add the tag yourself when the real version is posted? 

I intend splitting one of the patches into two as suggested by Will.


thanks,
Tobin.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.