LWN.net Logo

Reorganizing the address space

Reorganizing the address space

Posted Jul 1, 2004 2:16 UTC (Thu) by jreiser (subscriber, #11027)
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


(Log in to post comments)

Reorganizing the address space

Posted Jul 5, 2004 8:04 UTC (Mon) by glettieri (subscriber, #15705) [Link]

I believe that the value 0x08048000 originates in early Unix-like software for x86 from Santa Cruz

IIRC, the value 0x08048000 was chosen to accomodate the stack below the .text section (i.e., in the unused black space in the illustrations), growing downward. The 0x48000 bytes could be mapped by the same page table already required by the .text section (thus saving a page table in most cases), while the remaining 0x08000000 would allow more room for stack-hungry applications.

I have always wondered why the stack ended up in the upper portion of the address space. Is there any technical reason, or only historical? Anybody knows?

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds