[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
