Re:Re: Re: What is the memory region ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 inline

Regards,
Prabhunath G
Linux Trainer
Bangalore


On 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

[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux