aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/ld.so.md
diff options
context:
space:
mode:
Diffstat (limited to 'src/ld.so.md')
-rw-r--r--src/ld.so.md185
1 files changed, 104 insertions, 81 deletions
diff --git a/src/ld.so.md b/src/ld.so.md
index 6dc8c49..311d1be 100644
--- a/src/ld.so.md
+++ b/src/ld.so.md
@@ -1,9 +1,9 @@
# ld.so(8)
-## Environment variables
+## Environment Variables
```console
LD_PRELOAD=<l_so> colon separated list of libso's to be pre loaded
- LD_DEBUG=<opts> comman separated list of debug options
+ LD_DEBUG=<opts> comma separated list of debug options
=help list available options
=libs show library search path
=files processing of input files
@@ -11,7 +11,10 @@
=bindings show against which definition a symbol is bound
```
-## LD_PRELOAD load & init order
+## LD_PRELOAD: Initialization Order and Link Map
+Libraries specified in `LD_PRELOAD` are loaded from `left-to-right` but
+initialized from `right-to-left`.
+
```markdown
> ldd ./main
>> libc.so.6 => /usr/lib/libc.so.6
@@ -21,87 +24,107 @@
preloaded in this order
<--
initialized in this order
+```
+
+The preload order determines:
+- the order libraries are inserted into the `link map`
+- the initialization order for libraries
+
+For the example listed above the resulting `link map` will look like the
+following:
+
+```makrdown
+ +------+ +------+ +------+ +------+
+ | main | -> | liba | -> | libb | -> | libc |
+ +------+ +------+ +------+ +------+
+```
+
+This can be seen when running with `LD_DEBUG=files`:
+
+```makrdown
+ > LD_DEBUG=files LD_PRELOAD=liba.so:libb.so ./main
+ # load order (-> determines link map)
+ >> file=liba.so [0]; generating link map
+ >> file=libb.so [0]; generating link map
+ >> file=libc.so.6 [0]; generating link map
- - preload order determines the order libs are inserted into the link map
-
- - resulting link map:
- +------+ +------+ +------+ +------+
- | main | -> | liba | -> | libb | -> | libc |
- +------+ +------+ +------+ +------+
-
- - see preload and init order in action
- > LD_DEBUG=files LD_PRELOAD=liba.so:libb.so ./main
- # load order (-> determines link map)
- >> file=liba.so [0]; generating link map
- >> file=libb.so [0]; generating link map
- >> file=libc.so.6 [0]; generating link map
-
- # init order
- >> calling init: /usr/lib/libc.so.6
- >> calling init: <path>/libb.so
- >> calling init: <path>/liba.so
- >> initialize program: ./main
-
- - see the symbol lookup in action and therefore the link map order
- > LD_DEBUG=symbols,bindings LD_PRELOAD=liba.so:libb.so ./main
- >> symbol=memcpy; lookup in file=./main [0]
- >> symbol=memcpy; lookup in file=<path>/liba.so [0]
- >> symbol=memcpy; lookup in file=<path>/libb.so [0]
- >> symbol=memcpy; lookup in file=/usr/lib/libc.so.6 [0]
- >> binding file ./main [0] to /usr/lib/libc.so.6 [0]: normal symbol
- `memcpy' [GLIBC_2.14]
+ # init order
+ >> calling init: /usr/lib/libc.so.6
+ >> calling init: <path>/libb.so
+ >> calling init: <path>/liba.so
+ >> initialize program: ./main
```
+To verify the `link map` order we let `ld.so` resolve the `memcpy(3)` libc
+symbol (used in _main_) dynamically, while enabling `LD_DEBUG=symbols,bindings`
+to see the resolving in action.
-## dynamic linking (x86_64)
```makrdown
- - dynamic linking basically works via one indirect jump. It uses a
- combination of function trampolines (.plt) and a function pointer table
- (.got.plt). On the first call the trampoline sets up some metadata and
- then jumps to the ld.so runtime resolve function, which in turn patches
- the table with the correct function pointer.
- .plt ....... contains function trampolines, usually located in code
- segment (rx permission)
- .got.plt ... hold the function pointer table
-
- - following r2 dump shows this
- - [0x00401030] indirect jump for 'puts' using function pointer in
- _GLOBAL_OFFSET_TABLE_[3]
- - initially points to instruction behind 'puts' trampoline [0x00401036]
- - this pushes relocation index and then jumps to the first trampoline
- [0x00401020]
- - the first trampoline jumps to _GLOBAL_OFFSET_TABLE_[2] which will be
- filled at program startup by the ld.so with its resolve function
- - the resolve function fixes the relocation referenced by the
- relocation index pushed by the 'puts' trampoline
- - the relocation entry tells the resolve function which symbol to
- search for and where to put the function pointer
- > readelf -r <main>
- >> Relocation section '.rela.plt' at offset 0x4b8 contains 1 entry:
- >> Offset Info Type Sym. Value Sym. Name + Addend
- >> 000000404018 000200000007 R_X86_64_JUMP_SLO 0000000000000000 puts@GLIBC_2.2.5 + 0
- - offset points to _GLOBAL_OFFSET_TABLE_[3]
-
- [0x00401040]> pd 4 @ section..got.plt
- ;-- section..got.plt:
- ;-- .got.plt: ; [22] -rw- section size 32 named .got.plt
- ;-- _GLOBAL_OFFSET_TABLE_:
- 0x00404000 .qword 0x0000000000403e10 ; section..dynamic ; obj._DYNAMIC
- 0x00404008 .qword 0x0000000000000000
- ; CODE XREF from section..plt @ +0x6
- 0x00404010 .qword 0x0000000000000000
- ;-- reloc.puts:
- ; CODE XREF from sym.imp.puts @ 0x401030
- 0x00404018 .qword 0x0000000000401036 ; RELOC 64 puts
-
- [0x00401040]> pd 6 @ section..plt
- ;-- section..plt:
- ;-- .plt: ; [12] -r-x section size 32 named .plt
- ┌─> 0x00401020 ff35e22f0000 push qword [0x00404008]
- ╎ 0x00401026 ff25e42f0000 jmp qword [0x00404010]
- ╎ 0x0040102c 0f1f4000 nop dword [rax]
- ┌ 6: int sym.imp.puts (const char *s);
- └ ╎ 0x00401030 ff25e22f0000 jmp qword [reloc.puts]
- ╎ 0x00401036 6800000000 push 0
- └─< 0x0040103b e9e0ffffff jmp sym..plt
+ > LD_DEBUG=symbols,bindings LD_PRELOAD=liba.so:libb.so ./main
+ >> symbol=memcpy; lookup in file=./main [0]
+ >> symbol=memcpy; lookup in file=<path>/liba.so [0]
+ >> symbol=memcpy; lookup in file=<path>/libb.so [0]
+ >> symbol=memcpy; lookup in file=/usr/lib/libc.so.6 [0]
+ >> binding file ./main [0] to /usr/lib/libc.so.6 [0]: normal symbol `memcpy' [GLIBC_2.14]
```
+
+## Dynamic Linking (x86_64)
+Dynamic linking basically works via one indirect jump. It uses a combination of
+function trampolines (`.plt` section) and a function pointer table (`.got.plt`
+section).
+On the first call the trampoline sets up some metadata and then jumps to the
+`ld.so` runtime resolve function, which in turn patches the table with the
+correct function pointer.
+```makrdown
+ .plt ....... procedure linkage table, contains function trampolines, usually
+ located in code segment (rx permission)
+ .got.plt ... global offset table for .plt, holds the function pointer table
+```
+
+Using `radare2` we can analyze this in more detail:
+
+```makrdown
+ [0x00401040]> pd 4 @ section..got.plt
+ ;-- section..got.plt:
+ ;-- .got.plt: ; [22] -rw- section size 32 named .got.plt
+ ;-- _GLOBAL_OFFSET_TABLE_:
+ [0] 0x00404000 .qword 0x0000000000403e10 ; section..dynamic
+ [1] 0x00404008 .qword 0x0000000000000000
+ ; CODE XREF from section..plt @ +0x6
+ [2] 0x00404010 .qword 0x0000000000000000
+ ;-- reloc.puts:
+ ; CODE XREF from sym.imp.puts @ 0x401030
+ [3] 0x00404018 .qword 0x0000000000401036 ; RELOC 64 puts
+
+ [0x00401040]> pd 6 @ section..plt
+ ;-- section..plt:
+ ;-- .plt: ; [12] -r-x section size 32 named .plt
+ ┌─> 0x00401020 ff35e22f0000 push qword [0x00404008]
+ ╎ 0x00401026 ff25e42f0000 jmp qword [0x00404010]
+ ╎ 0x0040102c 0f1f4000 nop dword [rax]
+ ┌ 6: int sym.imp.puts (const char *s);
+ └ ╎ 0x00401030 ff25e22f0000 jmp qword [reloc.puts]
+ ╎ 0x00401036 6800000000 push 0
+ └─< 0x0040103b e9e0ffffff jmp sym..plt
+```
+
+- At address `0x00401030` in the `.plt` section we see the indirect jump for
+ `puts` using the function pointer in `_GLOBAL_OFFSET_TABLE_[3] (GOT)`.
+- `GOT[3]` initially points to instruction after the `puts` trampoline
+ `0x00401036`.
+- This pushes the relocation index `0` and then jumps to the first trampoline
+ `0x00401020`.
+- The first trampoline jumps to `GOT[2]` which will be filled at program
+ startup by the `ld.so` with its resolve function.
+- The `ld.so` resolve function fixes the relocation referenced by the
+ relocation index pushed by the `puts` trampoline.
+- The relocation entry at index `0` tells the resolve function which symbol to
+ search for and where to put the function pointer:
+ ```makrdown
+ > readelf -r <main>
+ >> Relocation section '.rela.plt' at offset 0x4b8 contains 1 entry:
+ >> Offset Info Type Sym. Value Sym. Name + Addend
+ >> 000000404018 000200000007 R_X86_64_JUMP_SLO 0000000000000000 puts@GLIBC_2.2.5 + 0
+ ```
+ As we can see the offset from relocation at index `0` points to `GOT[3]`.
+