Different addresses in ELF header and process virtual memory

Question

I see a process image via pmap under linux:

08048000 0 4 0 rx-- [my program] 08049000 0 4 4 rw--- [my program] 

The three segments above are segments of code, data and data that are all aligned with PAGESIZE (4K), but when I add the objdump -h command, the ELF headers display as follows:

 read-only code segment Load off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x00000448 memsz 0x00000448 flags rx read/write data segment Load off 0x00000448 vaddr 0x08049448 paddr 0x08049448 align 2**12 filesz 0x000000e8 memsz 0x00000104 flag rw- 

The ELF header says that the code segment and the data segment are addressed separately from 0x08048000,0x049448 in the virtual address, which differs from the process image in memory. I know that a code / data segment must be assigned to different PAGESIZEs, which can give them different security permissions. However, how can a program run if a real virtual object is different from an elf binary?

Answer 1

The method of loading the ELF program (and displaying the memory as a whole from files) is on the page. Thus, the addresses used, file offsets and size should be a multiple of the page size.

However, the program loader is smart enough to deal with sections that do not start or end exactly at the page border, rounding them to the page border, displaying more than required. Therefore, some additional data will be loaded from the file to fill the page, but it should not be accessed so that it does not matter.

In your example, the code segment is loaded at 0x08048000 from offset 0x0 with a size of 0x448. The address and offset are aligned, so the size should be rounded to the full page. The data segment is loaded from 0x08049448 from offset 0x448. They are not aligned, but compatible - the loader is rounded to several pages (0x08049000 and 0x000) and displays on this page. Note that this ends with the same page from the file as the code segment, so the page loads with two different addresses, one for read-only, the other for read-write-behind the scenes. Thus, the code and data all end up visible in two places of the process image, but it doesn’t matter - the code ends with rx at 0x8048000..0x8048447, and the data ends with rw- at 0x8049448..0x804954b, which is all that matters.