Hi!
> Inter-mmap randomization will decrease the predictability of later
> mmap() allocations, which should help make data structures harder to
> find in memory. In addition, this patch will also introduce unmapped
> gaps between pages, preventing linear overruns from one mapping to
> another anot
On Tue 2016-07-26 11:22:26, william.c.robe...@intel.com wrote:
> From: William Roberts
>
> This patch introduces the ability randomize mmap locations where the
> address is not requested, for instance when ld is allocating pages for
> shared libraries. It chooses to randomize based on the current
> linux-
> > m...@vger.kernel.org; linux-kernel@vger.kernel.org; akpm@linux-
> > foundation.org
> > Cc: keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.co
> > m;
> > je...@google.com; saly...@android.com; dcash...@android.com
> > Subject: Re: [kern
On Tue, 2016-07-26 at 11:22 -0700, william.c.robe...@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, in
on.org
> Cc: keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com
> Subject: Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization
>
> On Tue, 2016-07-26 at 11:22 -0700, william.c.robe...@intel.com wrot
>
> >
> > I would highly recommend studying those prior use cases and answering
> > those concerns before progressing too much further. As I've mentioned
> > elsewhere, you'll need to quantify the increased difficulty to the
> > attacker that your patch imposes. Personally, I would assess that
> >
> > No, I mean changes to mm/mmap.o.
>
>From UML build:
NEW:
1610 :
1610: 55 push %rbp
1611: 48 89 e5mov%rsp,%rbp
1614: 41 54 push %r12
1616: 48 8d 45 e8 lea-0x
...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>
> On Tue, Jul 26, 2016 at 09:06:30PM +, Roberts, William C wrote:
> > > From: ow
On Tue, Aug 2, 2016 at 9:57 AM, Roberts, William C
wrote:
> @nnk, disabling ASLR via set_arch() on Android, is that only for 32 bit
> address spaces where
> you had that problem?
Yes. Only 32 bit address spaces had the fragmentation problem.
--
Nick Kralevich | Android Security | n...@google.c
foundation.org; keesc...@chromium.org;
> gre...@linuxfoundation.org; je...@google.com; saly...@android.com;
> dcash...@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>
> On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper wrote:
> >> > One thing I didn&
> > It's very hard to quantify the benefits of fine-grained
> > randomization,
>
> ? N = # of possible addresses. The bigger N is, the more chances the
> attacker will trip up before finding what they were looking for.
If the attacker is forcing the creation of many objects with a function
poin
Hi Daniel,
On Fri, Jul 29, 2016 at 06:10:02AM -0400, Daniel Micay wrote:
> > > In the Project Zero Stagefright post
> > > (http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html)
> > > , we see that the linear allocation of memory combined with the
> > > low number of bits in the initi
> > In the Project Zero Stagefright post
> > (http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html)
> > ,
> > we see that the linear allocation of memory combined with the low
> > number of bits in the initial mmap offset resulted in a much more
> > predictable layout which aided the
On Wed, Jul 27, 2016 at 09:59:35AM -0700, Nick Kralevich wrote:
> On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper wrote:
> >> > One thing I didn't make clear in my commit message is why this is good.
> >> > Right
> >> > now, if you know An address within in a process, you know all offsets
> >> > d
On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper wrote:
>> > One thing I didn't make clear in my commit message is why this is good.
>> > Right
>> > now, if you know An address within in a process, you know all offsets done
>> > with
>> > mmap(). For instance, an offset To libX can yield libY by
>
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 rando
On Tue, Jul 26, 2016 at 09:06:30PM +, Roberts, William C wrote:
> > From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On
> > Behalf Of Jason Cooper
> > On Tue, Jul 26, 2016 at 08:13:23PM +, Roberts, William C wrote:
> > > > > From: Jason Cooper [mailto:ja...@lakedaemon.net] O
l.org; lkml > ker...@vger.kernel.org>; kernel-harden...@lists.openwall.com; Andrew
>> Morton ; Kees Cook ;
>> Greg KH ; Jeffrey Vander Stoep
>> ; saly...@android.com; Daniel Cashman
>>
>> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>>
>> My
nwall.com; a...@linux-foundation.org;
> keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>
> Hi William,
>
> On Tue, Jul 26, 2016 at
t; Morton ; Kees Cook ;
> Greg KH ; Jeffrey Vander Stoep
> ; saly...@android.com; Daniel Cashman
>
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>
> My apologies in advance if I misunderstand the purposes of this patch.
>
> IIUC, this patch adds a random gap betwee
Hi William,
On Tue, Jul 26, 2016 at 08:13:23PM +, Roberts, William C wrote:
> > > From: Jason Cooper [mailto:ja...@lakedaemon.net]
> > > On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.robe...@intel.com
> > > wrote:
> > > > Performance Measurements:
> > > > Using strace with -T option and
My apologies in advance if I misunderstand the purposes of this patch.
IIUC, this patch adds a random gap between various mmap() mappings,
with the goal of ensuring that both the mmap base address and gaps
between pages are randomized.
If that's the goal, please note that this behavior has caused
keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com; Roberts,
> William C
> Subject: Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap
> randomization
>
> On Tue, 2016-07-26 at 11:22 -0700, will
> harden...@lists.openwall.com; a...@linux-foundation.org;
> > keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> > je...@google.com; saly...@android.com; dcash...@android.com
> > Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> >
>
On Tue, 2016-07-26 at 11:22 -0700, william.c.robe...@intel.com wrote:
> From: William Roberts
>
> This patch introduces the ability randomize mmap locations where the
> address is not requested, for instance when ld is allocating pages
> for
> shared libraries. It chooses to randomize based on th
ation.org;
> keesc...@chromium.org; gre...@linuxfoundation.org; n...@google.com;
> je...@google.com; saly...@android.com; dcash...@android.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
>
> Hi William!
>
> On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.robe...@int
Hi William!
On Tue, Jul 26, 2016 at 11:22:26AM -0700, william.c.robe...@intel.com wrote:
> From: William Roberts
>
> This patch introduces the ability randomize mmap locations where the
> address is not requested, for instance when ld is allocating pages for
> shared libraries. It chooses to ran
From: William Roberts
This patch introduces the ability randomize mmap locations where the
address is not requested, for instance when ld is allocating pages for
shared libraries. It chooses to randomize based on the current
personality for ASLR.
Currently, allocations are done sequentially with
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.
29 matches
Mail list logo