Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization

[Daniel Micay <danielmicay@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Thu, 2016-08-04 at 16:55 +0000, Roberts, William C wrote:
> > 
> > -----Original Message-----
> > From: Daniel Micay [mailto:danielmicay@gmail.com]
> > Sent: Thursday, August 4, 2016 9:53 AM
> > To: kernel-hardening@lists.openwall.com; jason@lakedaemon.net;
> > linux-
> > mm@vger.kernel.org; linux-kernel@vger.kernel.org; akpm@linux-
> > foundation.org
> > Cc: keescook@chromium.org; gregkh@linuxfoundation.org; nnk@google.co
> > m;
> > jeffv@google.com; salyzyn@android.com; dcashman@android.com
> > Subject: Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap
> > randomization
> > 
> > On Tue, 2016-07-26 at 11:22 -0700, william.c.roberts@intel.com
> > wrote:
> > > 
> > > The recent get_random_long() change in get_random_range() and then
> > > the
> > > subsequent patches Jason put out, all stemmed from my tinkering
> > > with
> > > the concept of randomizing mmap.
> > > 
> > > Any feedback would be greatly appreciated, including any feedback
> > > indicating that I am idiot.
> > 
> > The RAND_THREADSTACK feature in grsecurity makes the gaps the way I
> > think
> > would be ideal, i.e. tracked as part of the appropriate VMA. It
> > would be
> > straightforward to make it more general purpose.
> 
> I am not familiar with that, thanks for pointing it out. I'll take a
> look when my time
> frees up for this again.

I'm actually wrong about that now that I look more closely...

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 851 bytes --]