在stackoverflow上看了What is the -fPIE option for position-independent executables in gcc and ld?，对其中的答案甚是满意，所以转载到博客中。
PIE(position-independent executables) is to support address space layout randomization (ASLR) in executable files.
Before the PIE mode was created, the program’s executable could not be placed at a random address in memory, only position independent code (PIC) dynamic libraries could be relocated to a random offset. It works very much like what PIC does for dynamic libraries, the difference is that a Procedure Linkage Table (PLT) is not created, instead PC-relative relocation is used.
After enabling PIE support in gcc/linkers, the body of program is compiled and linked as position-independent code. A dynamic linker does full relocation processing on the program module, just like dynamic libraries. Any usage of global data is converted to access via the Global Offsets Table (GOT) and GOT relocations are added.
Let’s see ASLR work on the PIE executable and change addresses across runs:
For the one with
-no-pie, everything is boring:
Breakpoint 1 at 0x40052a: file main.c, line 4.
Before starting execution,
break main sets a breakpoint at
Then, during both executions,
run stops at address
The one with
-pie however is much more interesting:
Breakpoint 1 at 0x754: file main.c, line 4.
Before starting execution, GDB just takes a “dummy” address that is present in the executable:
After it starts however, GDB intelligently notices that the dynamic loader placed the program in a different location, and the first break stopped at
Then, the second run also intelligently noticed that the executable moved again, and ended up breaking at
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space ensures that ASLR is on: How can I temporarily disable ASLR (Address space layout randomization)? | Ask Ubuntu.
set disable-randomization off is needed otherwise GDB, as the name suggests, turns off ASLR for the process by default to give fixed addresses across runs to improve the debugging experience: Difference between gdb addresses and “real” addresses? | Stack Overflow.
Furthermore, we can also observe that:
readelf -s ./no-pie.out | grep main
gives the actual runtime load address (pc pointed to the following instruction 4 bytes after):
68: 0000000000400526 21 FUNC GLOBAL DEFAULT 14 main
readelf -s ./pie.out | grep main
gives just an offset:
68: 0000000000000750 23 FUNC GLOBAL DEFAULT 14 main
By turning ASLR off (with either
set disable-randomization off), GDB always gives
main the address:
0x555555554754, so we deduce that the
-pie address is composed from:
0x555555554000 + random offset + symbol offset (750)
Another cool thing we can do is to play around with some assembly code to understand more concretely what PIE means.
We can do that with a Linux x86_64 freestanding assembly hello world:
and it assembles and runs fine with:
as -o main.o main.S
However, if we try to link it as PIE with (
--no-dynamic-linker is required as explained at: How to create a statically linked position independent executable ELF in Linux?):
ld --no-dynamic-linker -pie -o main.out main.o
then link will fail with:
ld: main.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
Because the line:
mov $message, %rsi # address of string to output
hardcodes the message address in the
mov operand, and is therefore not position independent.
If we instead write it in a position independent way:
lea message(%rip), %rsi # address of string to output
then PIE link works fine, and GDB shows us that the executable does get loaded at a different location in memory every time.
The difference here is that
lea encoded the address of
msg relative to the current PC address due to the
rip syntax, see also:How to use x64 RIP-relative addressing
Another fun thing that we can do is to put the
msg in the data section instead of
.o assembles to:
e: 48 8d 35 00 00 00 00 lea 0x0(%rip),%rsi # 15 <_start+0x15>
so the RIP offset is now
0, and we guess that a relocation has been requested by the assembler. We confirm that with:
readelf -r main.o
Relocation section '.rela.text' at offset 0x118 contains 1 entries:
R_X86_64_PC32 is a PC relative relocation that
ld can handle for PIE executables.
This experiment taught us that the linker itself checks the program can be PIE and marks it as such.
Then when compiling with GCC,
-pie tells GCC to generate position independent assembly.
But if we write assembly ourselves, we must manually ensure that we have achieved position independence.