[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 24 Jul 2011 22:18:55 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re: base address for shared libs
Solar,
On Sun, Jul 24, 2011 at 18:27 +0400, Solar Designer wrote:
> On Sun, Jul 24, 2011 at 12:51:42PM +0400, Vasiliy Kulikov wrote:
> > On Sat, Jul 23, 2011 at 20:22 +0400, Solar Designer wrote:
> > > At least on rhel5/openvz kernels, 32-bit processes get their shared libs
> > > loaded at different kinds of addresses on i686 vs. x86_64 kernels.
> > [...]
> > > Can you please look into this and likely fix it for mainline, as well as
> > > for rhel6/openvz when we're ready to move to those kernels? A fix for
> > > rhel5/openvz would also be welcome if it's easy to do.
> >
> > I'll look into it. However, I don't know whether upstream is OK with
> > force zeroing high order byte of libs address and artificially limiting
> > effective task's vm size. If not, it's probably should be made
> > configurable via kernel.randomize_va_space sysctl.
>
> I think you misunderstood me. I don't suggest forcing the high order
> byte to be zero; I merely suggest that the starting address should be
> 0x00110000.
Ah, sure. Best effort vs. enforcement.
> Oh, when vm86 is disallowed,
BTW, vm86 support is not even compiled on x86-64, even for x86-32
compatibility:
config VM86
bool "Enable VM86 support" if EXPERT
default y
depends on X86_32
> What does PaX do here?
I didn't hear PaX does some NUL protection of lib addresses. I'll look
into this.
Thanks,
--
Vasiliy
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.
