Lower RLIMIT_AS to 4GB after discussion with jschuh.

Lower RLIMIT_AS to 4GB after discussion with jschuh.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=171546

[Chris Evans, 2012-12-05 23:27:25]

As you requested :)

[jln (very slow on Chromium), 2012-12-05 23:33:23]

On 2012/12/05 23:27:25, Chris Evans wrote:
> As you requested :)

FYI, my rationale for 8GB was that:

1. 32 bits Chrome on Chrome OS must work in a 4GB address space (3GB if using a
32 bits kernels)
2. In the worst case, everything is a pointer and we'll need twice the memory
size in 64 bits.

As you can see I was fairly conservative. So 4GB LGTM. I'd be curious to hear
more of the background though.

[Chris Evans, 2012-12-05 23:46:52]

On 2012/12/05 23:33:23, Julien Tinnes wrote:
> On 2012/12/05 23:27:25, Chris Evans wrote:
> > As you requested :)
> 
> FYI, my rationale for 8GB was that:
> 
> 1. 32 bits Chrome on Chrome OS must work in a 4GB address space (3GB if using
a
> 32 bits kernels)
> 2. In the worst case, everything is a pointer and we'll need twice the memory
> size in 64 bits.
> 
> As you can see I was fairly conservative. So 4GB LGTM. I'd be curious to hear
> more of the background though.

Thanks for the LGTM!

The additional background for this is that Justin was surprised it was so high.
We were discussing a compiler-level defence that can be defeated if the attacker
knows _any_ address, so we were discussing how a large heap spray interacts with
ASLR on 64-bit Linux.

Whilst chatting, we realized that 4GB would defend against some other common bug
patterns such as storing a length in a 32-bit int, and growing the buffer bit by
bit with "len += small_increment; realloc()".

[jln (very slow on Chromium), 2012-12-05 23:52:30]

On 2012/12/05 23:46:52, Chris Evans wrote:
> On 2012/12/05 23:33:23, Julien Tinnes wrote:
> > On 2012/12/05 23:27:25, Chris Evans wrote:
> > > As you requested :)
> > 
> > FYI, my rationale for 8GB was that:
> > 
> > 1. 32 bits Chrome on Chrome OS must work in a 4GB address space (3GB if
using
> a
> > 32 bits kernels)
> > 2. In the worst case, everything is a pointer and we'll need twice the
memory
> > size in 64 bits.
> > 
> > As you can see I was fairly conservative. So 4GB LGTM. I'd be curious to
hear
> > more of the background though.
> 
> Thanks for the LGTM!
> 
> The additional background for this is that Justin was surprised it was so
high.
> We were discussing a compiler-level defence that can be defeated if the
attacker
> knows _any_ address, so we were discussing how a large heap spray interacts
with
> ASLR on 64-bit Linux.
> 
> Whilst chatting, we realized that 4GB would defend against some other common
bug
> patterns such as storing a length in a 32-bit int, and growing the buffer bit
by
> bit with "len += small_increment; realloc()".

It's worth trying at least. I wish we could limit "committed" memory, but Linux
doesn't allow us to do that.

Limiting the address space is a bit more risky because in theory a memory
allocator could map a huge chunk of memory as then use it as needed, relying on
Linux' on-demand paging.

I didn't see this happen so far, except with ASAN (which as you can see is
excluded).

[jschuh, 2012-12-06 16:27:37]

On 2012/12/05 23:52:30, Julien Tinnes wrote:
> On 2012/12/05 23:46:52, Chris Evans wrote:
> > On 2012/12/05 23:33:23, Julien Tinnes wrote:
> > > On 2012/12/05 23:27:25, Chris Evans wrote:
> > > > As you requested :)
> > > 
> > > FYI, my rationale for 8GB was that:
> > > 
> > > 1. 32 bits Chrome on Chrome OS must work in a 4GB address space (3GB if
> using
> > a
> > > 32 bits kernels)
> > > 2. In the worst case, everything is a pointer and we'll need twice the
> memory
> > > size in 64 bits.
> > > 
> > > As you can see I was fairly conservative. So 4GB LGTM. I'd be curious to
> hear
> > > more of the background though.
> > 
> > Thanks for the LGTM!
> > 
> > The additional background for this is that Justin was surprised it was so
> high.
> > We were discussing a compiler-level defence that can be defeated if the
> attacker
> > knows _any_ address, so we were discussing how a large heap spray interacts
> with
> > ASLR on 64-bit Linux.
> > 
> > Whilst chatting, we realized that 4GB would defend against some other common
> bug
> > patterns such as storing a length in a 32-bit int, and growing the buffer
bit
> by
> > bit with "len += small_increment; realloc()".
> 
> It's worth trying at least. I wish we could limit "committed" memory, but
Linux
> doesn't allow us to do that.
> 
> Limiting the address space is a bit more risky because in theory a memory
> allocator could map a huge chunk of memory as then use it as needed, relying
on
> Linux' on-demand paging.
> 
> I didn't see this happen so far, except with ASAN (which as you can see is
> excluded).

lgtm. btw, in Windows I planned to add this as a limit in tcmalloc, which should
be a closer analog to committed memory.