On Sat, 2003-05-03 at 11:56, Carl-Daniel Hailfinger wrote:
> Ingo Molnar wrote:
> > On Fri, 2 May 2003, Carl-Daniel Hailfinger wrote:
> >
> >
> >>Ingo Molnar wrote:
> >>
> >>>Furthermore, the kernel also remaps all PROT_EXEC mappings to the
> >>>so-called ASCII-armor area, which on x86 is the addresses 0-16MB. These
>
> What happens if the ASCII-armor area is full, i.e. sum(PROT_EXEC sizes)
> >16MB for a given binary (Mozilla comes to mind)? Does loading fail or
> does the binary run without any errors, giving the user a false sense of
> security?
the binary will run without errors. And all the libs are still below the
main binary (the space for that is much bigger, like 128Mb) so the
executable limit is still the end of the main binary.
>
> > the ASCII-armor, more precisely, is between addresses 0x00000000 and
> > 0x0100ffff. Ie. 16 MB + 64K. [in the remaining 64K the \0 character is in
> > the second byte of the address.] So the 0x01003fff address is still inside
> > the ASCII-armor.
>
> Thanks. However, that brings me to the next question:
>
> 01000000-01004000 r-xp 00000000 16:01 2036120 /home/mingo/cat-lowaddr
>
> I was wondering why the executable parts of the binary start at the 16
> MB boundary. Is this always the case or just something that happens with
> cat? In the first case, that would be bad for any binary with a
> contiguous executable area bigger than 64K.
the start address of the binary is determined by ld at link time. This
cat binary was forced to go at exactly this address.
The patch to binutils in Ingo's directory will add the linker option to
move apps in this area; it will actually use a lower address than
01000000 to allow for bigger binaries. Obviously this 16Mb zone won't
fit all apps, but daemons like sendmail and sshd etc all just fit.
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:18 EST