Reorganizing the address space
Posted Jul 1, 2004 2:16 UTC (Thu) by jreiser
Parent article: Reorganizing the address space
The default .text base on x86 is 0x08048000, chosen by the default linker script for static binding (which is revealed by ld --verbose). I believe that the value 0x08048000 originates in early Unix-like software for x86 from Santa Cruz. The value 0x40000000 is the kernel symbol TASK_UMAPPED_BASE. Another reason to avoid the address range 0 to 0x110000 (1MB + 64KB) is for use by vm86 mode. Fedora Core 1 and 2 also have features exec-shield and exec-shield-randomize, which default to 1 ("on") in /proc/sys/kernel. Exec-shield tries to put an mmap() that specifies PROT_EXEC (and not MAP_FIXED) into the range 1MB to 16MB, because the return address to a CALL from that range has a high byte of 0. This tends to limit damage by malware that overwrites the stack (and hence return addresses) with strings, because '\0' occurs infrequently in the new data. Exec-shield-randomize also varies the base address of such an mmap(), which tends to improve the chance of avoiding a malware attack that depends on fixed addresses. Preference for low addresses with PROT_EXEC also enhances the effectiveness of setting the segment limit for the cs code segment to the least upper bound of pages having PROT_EXEC. This is another [partial] defense against malware.
The details of kernel policy on mmap() are more important than they should be, partly because Linux lacks a binary structure interface to /proc/pid/maps. It is tedious and painful to have to parse variable-length character data that contains non-quoted literal strings. Nothing prevents a filename from having a path component that looks like a line from /proc/pid/maps. Win32 has a binary structure interface VirtualQuery() which is concise, fast, and easy to decode. With such an interface, it is easy for the user to manage placement policy for all the pages of the address space. On Linux, it requires a dirty hack: http://www.BitWagon.com/tub.html
to post comments)