What's the memory before 0x08048000 used for in 32 bit machine?

Question

In Linux, I learned that every process stores data starting at 0x08048000 in 32 bit machine (and 0x00400000 in 64 bit machine).

But I don't know the reason why starting from there. What's the memory before 0x08048000 used for?

Update: Some people think it's mapped for the kernel. However as far as I know, Linux kernel uses the high-end memory starting after the user stack.

Sandysandye

Answer 1

The answer is really: a bunch of things. There is no magical meaning to the load address of the executable and pretty much anything can be mapped to the lower addresses. Common examples including: C library (such as the C library), the dynamic loader ld.so and the kernel VDSO (kernel mapped dynamic code library that provides some of the interface to the kernel in x86 Linux). But you can pretty much map anything you desire there, using the mmap() system call.

For example on my specific machine the map is as follows (acquired but "cat /proc/self/maps"):

gby@watson:~$ cat /proc/self/maps 
001c0000-00317000 r-xp 00000000 08:01 245836     /lib/libc-2.12.1.so
00317000-00318000 ---p 00157000 08:01 245836     /lib/libc-2.12.1.so
00318000-0031a000 r--p 00157000 08:01 245836     /lib/libc-2.12.1.so
0031a000-0031b000 rw-p 00159000 08:01 245836     /lib/libc-2.12.1.so
0031b000-0031e000 rw-p 00000000 00:00 0 
00376000-00377000 r-xp 00000000 00:00 0          [vdso]
00852000-0086e000 r-xp 00000000 08:01 245783     /lib/ld-2.12.1.so
0086e000-0086f000 r--p 0001b000 08:01 245783     /lib/ld-2.12.1.so
0086f000-00870000 rw-p 0001c000 08:01 245783     /lib/ld-2.12.1.so
08048000-08051000 r-xp 00000000 08:01 2244617    /bin/cat
08051000-08052000 r--p 00008000 08:01 2244617    /bin/cat
08052000-08053000 rw-p 00009000 08:01 2244617    /bin/cat
09ab5000-09ad6000 rw-p 00000000 00:00 0          [heap]
b7502000-b7702000 r--p 00000000 08:01 4456455    /usr/lib/locale/locale-archive
b7702000-b7703000 rw-p 00000000 00:00 0 
b771b000-b771c000 r--p 002a1000 08:01 4456455    /usr/lib/locale/locale-archive
b771c000-b771e000 rw-p 00000000 00:00 0 
bfbd9000-bfbfa000 rw-p 00000000 00:00 0          [stack]

Ladin

Some distros (e.g. RHEL6) have even ditched the 0x08048000 thing completely by linking programs with DYNAMIC flag, making their segments be allocated alongside .so's. – Ruthi

Answer 2

The start address for loading executable code is determined by the ELF headers for the executable. For example:

/bin/ls
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08049bb0

There's nothing stopping an executable from specifying a different load address; for whatever reason the default linker settings put it there. You could override with a custom linker script.

By default, on linux/x86, you won't see low addresses below 0x08000000 used for much; although the kernel may use it if requested in a mmap call, or if it runs out of room for mmaps. Additionally, there have been proposals to use addresses in the 0x00000000 - 0x01000000 range for library mappings, to make buffer overflows more difficult (by embedding a NUL byte to terminate strings).

Delisadelisle

All processes have separate virtual address translation tables. So lot of them could have same start address, translating to different physical addresses. – Cognac

Answer 3

The load address is arbitrary, but was standardized back with SYSV for x86. It's different for every architecture. What goes above and below is also arbitrary, and is often taken up by linked in libraries and mmap() regions.

Popham

Answer 4

Typical Load Map for x86 for 32 bit Small static app looks like :

 Address     Contents

 0x08048000  code
 0x08052000  data
 0x0805A000  bss (zero data)
 0x08072000  end of data (brk marker)
 0xBFFFE000  stack

All this being in reverse - stack being on top and moving down while data moving up. My guess is the address before 0x08048000 are statically linked something similar to the MBR per OS.

Annuitant

If your program image is loaded at 0x0848000, you won't see anything below that - no "MBR" or anything. – Delisadelisle