.rodata section loaded in executable page

So out of curiosity, I tried to run this code today (compiled with gcc -m32 1.c):

int main(void)
{
    // EB is the opcode for jmp rel/8
    // FE is hex for -2
    // So this is essentially an infinite loop

    ((void(*)(void))"\xEB\xFE")();
}

... and it worked! No segfaults, the program (correctly?) goes into an infinite loop. Looking at the disassembly (objdump -d a.out), you can see the call to... whatever is at address 0x8048480:

080483d6 <main>:
 ....
 80483e7:   b8 80 84 04 08          mov    $0x8048480,%eax
 80483ec:   ff d0                   call   *%eax
 ....

objdump -s -j .rodata a.out gives:

Contents of section .rodata:
 8048478 03000000 01000200 ebfe00             ...........
                           ~~~~

So it is indeed executing the string, which is stored in the .rodata section. So I ran readelf --sections a.out and got:

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 000020 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          080481cc 0001cc 000040 10   A  6   1  4
  [ 6] .dynstr           STRTAB          0804820c 00020c 000045 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          08048252 000252 000008 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0804825c 00025c 000020 00   A  6   1  4
  [ 9] .rel.dyn          REL             0804827c 00027c 000008 08   A  5   0  4
  [10] .rel.plt          REL             08048284 000284 000008 08  AI  5  23  4
  [11] .init             PROGBITS        0804828c 00028c 000023 00  AX  0   0  4
  [12] .plt              PROGBITS        080482b0 0002b0 000020 04  AX  0   0 16
  [13] .plt.got          PROGBITS        080482d0 0002d0 000008 00  AX  0   0  8
  [14] .text             PROGBITS        080482e0 0002e0 000182 00  AX  0   0 16
  [15] .fini             PROGBITS        08048464 000464 000014 00  AX  0   0  4
  [16] .rodata           PROGBITS        08048478 000478 00000b 00   A  0   0  4
  [17] .eh_frame_hdr     PROGBITS        08048484 000484 000034 00   A  0   0  4
  [18] .eh_frame         PROGBITS        080484b8 0004b8 0000e0 00   A  0   0  4
  [19] .init_array       INIT_ARRAY      08049f0c 000f0c 000004 04  WA  0   0  4
  [20] .fini_array       FINI_ARRAY      08049f10 000f10 000004 04  WA  0   0  4
  [21] .dynamic          DYNAMIC         08049f14 000f14 0000e8 08  WA  6   0  4
  [22] .got              PROGBITS        08049ffc 000ffc 000004 04  WA  0   0  4
  [23] .got.plt          PROGBITS        0804a000 001000 000010 04  WA  0   0  4
  [24] .data             PROGBITS        0804a010 001010 000008 00  WA  0   0  4
  [25] .bss              NOBITS          0804a018 001018 000004 00  WA  0   0  1
  [26] .comment          PROGBITS        00000000 001018 00001a 01  MS  0   0  1
  [27] .symtab           SYMTAB          00000000 001034 0003f0 10     28  45  4
  [28] .strtab           STRTAB          00000000 001424 0001bd 00      0   0  1
  [29] .shstrtab         STRTAB          00000000 0015e1 000105 00      0   0  1

So in the ELF binary, the section is marked non-executable. But in memory, the page is executable (cat /proc/xxx/maps):

08048000-08049000 r-xp 00000000 08:01 663551 /home/andrew/Desktop/a.out
08049000-0804a000 r--p 00000000 08:01 663551 /home/andrew/Desktop/a.out
0804a000-0804b000 rw-p 00001000 08:01 663551 /home/andrew/Desktop/a.out

My original guess was that the sections too closely-spaced (there are both AX and A sections in the 08048000-08049000 range), so Linux is forced to give the page the union of the ELF permission bits (AX | A == AX). However, even after increasing the size of the .rodata section (by adding many long strings), all of the pages containing the .rodata section are still executable. Why is this?

(For the record, I'm running on Linux kernel 4.11.7, GCC 7.1.1, and compiling as 64-bit still exhibits this behavior)

My original guess was that the segments too closely-spaced

You should not call sections segments (ELF has both, and they mean different things).

Sections only matter at static link time, and can be completely removed (are not needed at runtime). Only segments matter at runtime, and a typical ELF binary will have two segments with R-X and RW- permissions.

The .rodata section is usually merged with .text section and put into the executable segment. You can change that with the --rosegment flag if you use gold linker (patch which introduced this).

You can see section to segment mapping in the readelf -Wl a.out output.

Update:

Can there ever be a situation where .rodata needs to be executable, or is it for optimization, or something else?

There are no portable situations where .rodata needs to be executable. It is possible to construct a non-portable program that requires it, as you've done in your question.

Merging of .rodata and .text is an optimization: it requires two mmap calls instead of three (a program linked with --rosegment will have three separate PT_LOAD segments with R-X, R-- and R-W protections) and also fragments the virtual space less. In addition, on Linux there is a system-wide limit on total mappings, so you'll reduce the total number of programs you can run at once by 50% if you link everything with --rosegment.

Update 2:

Recent Linux distributions stopped merging .text and .rodata, and now have three or four separate LOAD segments. See this answer.

Recommended topics

Hot tags