Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110812100447.GB6743@openwall.com>
Date: Fri, 12 Aug 2011 14:04:47 +0400
From: Solar Designer <solar@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: base address for shared libs

On Fri, Aug 12, 2011 at 01:52:19PM +0400, Vasiliy Kulikov wrote:
> There are 2 allocation logics, top down and bottom up:
> 
> http://lxr.free-electrons.com/source/mm/mmap.c#L1372
> 
> http://lxr.free-electrons.com/source/mm/mmap.c#L1444
> 
> If use top down logic (start from 0x01000000 as the end of the library)
> then some gap at 0x00110000 will be wasted.  With bottom up logic I'll
> simply have the last library partly being in ASCII-armor zone, the end
> of it will be located after 0x01000000, but no waste of vm space.
> 
> Or you mean anything else?

You're right.  I just didn't realize the words "bottom up" were used in
kernel source to mean that.

> OK.  However, I don't see much sense in sizes between 10 and 16.  If we
> want to use ASCII-armor or warried about vm-hungry apps, then use 10
> bits.

Why not use 14 in such cases, which still fits in the below-binary range
and thus does not reduce the maximum continuous allocation size?

> But if use distros with their default 12 bits in containers, it makes
> sense to protect them with a probabilistic measure, though.

I don't understand what you mean here.  The distros' default 12 bits -
are they patched into those distros' kernels?  If so, they do not apply
to use in containers (where only userlands are used).

Alexander

Powered by blists - more mailing lists

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