Thanks, Prabhunath!
Great detail, very helpful!
Regards,
Jacky
在 2013-03-08 15:37:27，"Prabhu nath" <gprabhunath@xxxxxxxxx> 写道：
On Thu, Mar 7, 2013 at 7:38 PM, Jacky <jackyclivia@xxxxxxx> wrote:
Thanks Prabhunath!
The following is section header table:
==============================
readelf -S /bin/cat
There are 28 section headers, starting at offset 0xb260:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 08048154 000154 000013 00 A 0 0 1
[ 2] .note.ABI-tag NOTE 08048168 000168 000020 00 A 0 0 4
[ 3] .note.gnu.build-i NOTE 08048188 000188 000024 00 A 0 0 4
[ 4] .gnu.hash GNU_HASH 080481ac 0001ac 000044 04 A 5 0 4
[ 5] .dynsym DYNSYM 080481f0 0001f0 0004e0 10 A 6 1 4
[ 6] .dynstr STRTAB 080486d0 0006d0 000349 00 A 0 0 1
[ 7] .gnu.version VERSYM 08048a1a 000a1a 00009c 02 A 5 0 2
[ 8] .gnu.version_r VERNEED 08048ab8 000ab8 000090 00 A 6 1 4
[ 9] .rel.dyn REL 08048b48 000b48 000030 08 A 5 0 4
[10] .rel.plt REL 08048b78 000b78 000228 08 A 5 12 4
[11] .init PROGBITS 08048da0 000da0 000024 00 AX 0 0 4
[12] .plt PROGBITS 08048dd0 000dd0 000460 04 AX 0 0 16
[13] .text PROGBITS 08049230 001230 006f2c 00 AX 0 0 16
[14] .fini PROGBITS 0805015c 00815c 000015 00 AX 0 0 4
[15] .rodata PROGBITS 08050180 008180 000e86 00 A 0 0 32
[16] .eh_frame_hdr PROGBITS 08051008 009008 0002d4 00 A 0 0 4
[17] .eh_frame PROGBITS 080512dc 0092dc 000d30 00 A 0 0 4
[18] .init_array INIT_ARRAY 08053f04 00af04 000004 00 WA 0 0 4
[19] .fini_array FINI_ARRAY 08053f08 00af08 000004 00 WA 0 0 4
[20] .jcr PROGBITS 08053f0c 00af0c 000004 00 WA 0 0 4
[21] .dynamic DYNAMIC 08053f10 00af10 0000e8 08 WA 6 0 4
[22] .got PROGBITS 08053ff8 00aff8 000008 04 WA 0 0 4
[23] .got.plt PROGBITS 08054000 00b000 000120 04 WA 0 0 4
[24] .data PROGBITS 08054120 00b120 00003c 00 WA 0 0 4
[25] .bss NOBITS 08054160 00b15c 0005c4 00 WA 0 0 32
[26] .gnu_debuglink PROGBITS 00000000 00b15c 000008 00 0 0 1
[27] .shstrtab STRTAB 00000000 00b164 0000fc 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
==============================
But, according the kernel elf loader :
linux-3.7.4/fs/binfmt_elf.c:
static int load_elf_binary(...)
{
...
for(i = 0, elf_ppnt = elf_phdata;
i < loc->elf_ex.e_phnum; i++, elf_ppnt++) {
...
if (elf_ppnt->p_type != PT_LOAD)
continue;
...
}
The kernel elf loader just load PT_LOAD segment, but GNU_RELRO is not PT_LOAD type ?GNU_RELRO is a subset of PT_LOAD 2 i.e. 2nd Loadable segment. This type of adjustment I had seen in WindRiver distribution of Linux. This is actually made to avoid unnecessary application crash (segmentation faults) which I will explain later.
First Let us look at Section to Segment mapping.
Sections 1 to 17 which have access permissions AX are mapped to 1st Loadable segment (Code)
Sections 18 to 26 which have access permissions WA are mapped to 2nd Loadable segment (Data)
Of these Section 18 to 22 are also mapped to GNU_RELRO.
When an application is initiated for execution sections 18 to 22 will be accessed by the dynamic linker to edit few locations . Since dynamic linker code also will be mapped to the virtual address space of the application (see /proc/self/maps), virtual address associated to sections 18 to 22 should have write permissions for the dynamic linker to write into those sections.
And the application's code has explicitly nothing to do with the sections 18 to 22, though the execution control passes through these sections without the knowledge of the application programmer.
Thus once the dynamic linker finishes its job, this trick is done to split the virtual address region 08053000-08055000 to
08053000-08054000 r--p 0000a000 08:01 261656 /bin/cat
08054000-08055000 rw-p 0000b000 08:01 261656 /bin/cat
If you carefully observe, section 23 (.got.plt) is still part of the virtual address region 08054000-08055000, even though the application code has nothing to do with this section explicitly. This is because of lazy binding adopted by dynamic linker. The dynamic linker will put its hand on to this section when the application invokes some of the library functions.
Why this trick ?
Suppose the entire virtual address region 08053000-08055000 is RW. The application can inadvertently access the addresses which are mapped to section 18 to 22 and cause the application to crash.
For eg.
int a[3]; // Suppose address of a is 0x08054160 belongs to .bss
int main()
{
a[-0x168] = 12;
return 0;
}
Since a[-0x168] is *(a-0x168). This will generate the address 0x08053FF8 which belongs to .got section (sec 22).
This code will be writing into the .got section and cause the app. to crash at some point later.
To avoid this type of errors, sections 18 to 22 will be marked as READONLY, so that the kernel can do a access type
validation of the generated address and not allow the program to write into READONLY area.
Regards,
Prabhunath G
Linux Trainer
Bangalore
At 2013-03-07 18:53:46,"Prabhu nath" <gprabhunath@xxxxxxxxx> wrote:
Looks like they have added a new section GNU_RELRO in the later versions. The one you are referring is read-only section. It would be nice if you share the section header table.
Plz see inlineRegards,
Prabhunath G
Linux Trainer
BangaloreOn Thu, Mar 7, 2013 at 3:31 PM, Jacky <jackyclivia@xxxxxxx> wrote:Dear all,
This is the Program Header for "cat" info:
================================
readelf -l /bin/cat
...
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x00120 0x00120 R E 0x4
INTERP 0x000154 0x08048154 0x08048154 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x0a00c 0x0a00c R E 0x1000
LOAD 0x00af04 0x08053f04 0x08053f04 0x00258 0x00820 RW 0x1000
DYNAMIC 0x00af10 0x08053f10 0x08053f10 0x000e8 0x000e8 RW 0x4
NOTE 0x000168 0x08048168 0x08048168 0x00044 0x00044 R 0x4
GNU_EH_FRAME 0x009008 0x08051008 0x08051008 0x002d4 0x002d4 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
GNU_RELRO 0x00af04 0x08053f04 0x08053f04 0x000fc 0x000fc R 0x1
==============================
So there are just 2 PT_LOAD segments. But why kernel maps 3 memory regions ? The following is the maps output:
Though the second PT_LOAD starts at the file offset 0xaf04, The first fc bytes belong to GNU_RELRO segment (The last entry in the Program Header). If you add af04 +fc you get afff. Looks like they have placed this section advertently in such a way that the actual DATA segment will start at the next virtual address page boundary 0x08054000. Thus the GNU_RELRO section with read-only permissions is placed in the separate virtual address region.
This is the result of the maps file you see below.============================
cat /proc/self/maps
08048000-08053000 r-xp 00000000 08:01 261656 /bin/cat
08053000-08054000 r--p 0000a000 08:01 261656 /bin/cat
08054000-08055000 rw-p 0000b000 08:01 261656 /bin/cat
09b58000-09b79000 rw-p 00000000 00:00 0 [heap]
b75bd000-b75be000 rw-p 00000000 00:00 0
b75be000-b7761000 r-xp 00000000 08:01 523958 /lib/i386-linux-gnu/libc-2.15.so
...
==================
The above output, there are 3 memory regions for "/bin/cat", and what is the following segment:
08053000-08054000 r--p 0000a000 08:01 261656 /bin/cat
According the 'cat' program header, there is no "r" segment.
Regards,
Jacky
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
