[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5797F78A.2000600@intel.com>
Date: Tue, 26 Jul 2016 16:51:38 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jason Cooper <jason@...edaemon.net>,
"Roberts, William C" <william.c.roberts@...el.com>
Cc: "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"keescook@...omium.org" <keescook@...omium.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"nnk@...gle.com" <nnk@...gle.com>,
"jeffv@...gle.com" <jeffv@...gle.com>,
"salyzyn@...roid.com" <salyzyn@...roid.com>,
"dcashman@...roid.com" <dcashman@...roid.com>
Subject: Re: [PATCH] [RFC] Introduce mmap randomization
On 07/26/2016 02:44 PM, Jason Cooper wrote:
>> > I'd likely need to take a small sample of programs and examine them,
>> > especially considering That as gaps are harder to find, it forces the
>> > randomization down and randomization can Be directly altered with
>> > length on mmap(), versus randomize_addr() which didn't have this
>> > restriction but OOM'd do to fragmented easier.
> Right, after the Android feedback from Nick, I think you have a lot of
> work on your hands. Not just in design, but also in developing convincing
> arguments derived from real use cases.
Why not just have the feature be disabled on 32-bit by default? All of
the Android problems seemed to originate with having a constrained
32-bit address space.
Powered by blists - more mailing lists