Re: [kernel-hardening] base address for shared libs

[Vasiliy Kulikov <segoon@openwall.com>]

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