ELF - Verifying executable memory regions - linux

Question

I'm learning about elf binaries. I want to manually verify that the code written in the program is in an executable region of memory (same for code for shared library that will be linked).
I have a simple program:
int main() { return 0; }
When I do:
readelf -a myprog
I get the following:
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 000010 08 A 5 12 4
[11] .init PROGBITS 08048294 000294 00002e 00 AX 0 0 4
[12] .plt PROGBITS 080482d0 0002d0 000030 04 AX 0 0 16
[13] .text PROGBITS 08048300 000300 00016c 00 AX 0 0 16
[14] .fini PROGBITS 0804846c 00046c 00001a 00 AX 0 0 4
[15] .rodata PROGBITS 08048488 000488 000008 00 A 0 0 4
[16] .eh_frame_hdr PROGBITS 08048490 000490 000034 00 A 0 0 4
[17] .eh_frame PROGBITS 080484c4 0004c4 0000c4 00 A 0 0 4
[18] .ctors PROGBITS 08049f14 000f14 000008 00 WA 0 0 4
[19] .dtors PROGBITS 08049f1c 000f1c 000008 00 WA 0 0 4
[20] .jcr PROGBITS 08049f24 000f24 000004 00 WA 0 0 4
[21] .dynamic DYNAMIC 08049f28 000f28 0000c8 08 WA 6 0 4
[22] .got PROGBITS 08049ff0 000ff0 000004 04 WA 0 0 4
[23] .got.plt PROGBITS 08049ff4 000ff4 000014 04 WA 0 0 4
[24] .data PROGBITS 0804a008 001008 000008 00 WA 0 0 4
[25] .bss NOBITS 0804a010 001010 000008 00 WA 0 0 4
[26] .comment PROGBITS 00000000 001010 00002a 01 MS 0 0 1
[27] .shstrtab STRTAB 00000000 00103a 0000fc 00 0 0 1
[28] .symtab SYMTAB 00000000 0015e8 000400 10 29 45 4
[29] .strtab STRTAB 00000000 0019e8 0001ea 00 0 0 1
To check whether the code of the program is executable, I can see the .text section with the flags AX. Is the X here for making the code inside my main() function is executable ?
Which section will the shared library (e.g. glibc) be loaded into when the program is dynamically linked at run time ? I found explanation online which discussed use of GOT,PLT in context of dynamic linking. The only sections with the mark X are init, plt and fini (in addition to text). Are shared libraries linked into one of these sections to make sure their code is executable when program starts execution ?
(It would be great if some reference(s) could be pointed at when answering the above)

Answer 1

Is the X here for making the code inside my main() function is executable ?
Correct. Although more than just your main() function is involved; there is some other code which is linked into your executable that is also contained in this section.
Which section will the shared library (e.g. glibc) be loaded into when the program is dynamically linked at run time ?
None of them. The shared library is a separate ELF object, and has its own sections, some of which are executable; it is essentially loaded alongside your executable, not into it. That is, the resulting image in memory will contain both your executable's .text section and a number of other .text (and other types of) sections from all the shared libraries it has loaded.
For example, here is the content of /proc/self/maps from a running /bin/cat process on my Linux system. The format of this output is different from what readelf is showing you, but some similarities should become apparent:
00400000-0040b000 r-xp 00000000 08:00 32968 /bin/cat
0060a000-0060b000 r--p 0000a000 08:00 32968 /bin/cat
0060b000-0060c000 rw-p 0000b000 08:00 32968 /bin/cat
0242a000-0244b000 rw-p 00000000 00:00 0 [heap]
7fdf299a2000-7fdf29c6b000 r--p 00000000 08:00 949 /usr/lib/locale/locale-archive
7fdf29c6b000-7fdf29e26000 r-xp 00000000 08:00 18508 /lib/x86_64-linux-gnu/libc-2.19.so
7fdf29e26000-7fdf2a025000 ---p 001bb000 08:00 18508 /lib/x86_64-linux-gnu/libc-2.19.so
7fdf2a025000-7fdf2a029000 r--p 001ba000 08:00 18508 /lib/x86_64-linux-gnu/libc-2.19.so
7fdf2a029000-7fdf2a02b000 rw-p 001be000 08:00 18508 /lib/x86_64-linux-gnu/libc-2.19.so
7fdf2a02b000-7fdf2a030000 rw-p 00000000 00:00 0
7fdf2a030000-7fdf2a053000 r-xp 00000000 08:00 18255 /lib/x86_64-linux-gnu/ld-2.19.so
7fdf2a246000-7fdf2a249000 rw-p 00000000 00:00 0
7fdf2a250000-7fdf2a252000 rw-p 00000000 00:00 0
7fdf2a252000-7fdf2a253000 r--p 00022000 08:00 18255 /lib/x86_64-linux-gnu/ld-2.19.so
7fdf2a253000-7fdf2a254000 rw-p 00023000 08:00 18255 /lib/x86_64-linux-gnu/ld-2.19.so
7fdf2a254000-7fdf2a255000 rw-p 00000000 00:00 0
7ffd516aa000-7ffd516cb000 rw-p 00000000 00:00 0 [stack]
7ffd517f9000-7ffd517fb000 r--p 00000000 00:00 0 [vvar]
7ffd517fb000-7ffd517fd000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
In particular, you can see three sections were loaded from /bin/cat at the top: the first one is executable (r-xp), the second one is read-only (r--p), and the third is read-write (rw-p). Additionally, there are a number of executable and non-executable segments mapped from libc-2.19.so below that, as well as from ld-2.19.so (the dynamic linker).
(There are also some somewhat mysterious segments appearing in this dump, including [vdso] and [vsyscall]. These are mapped into the process by the kernel, and are difficult to explain; I won't get into them here.)