Qu'est-ce que l'-fPIE option indépendante de la position des exécutables dans le gcc et ld?

Minimum praticable exemple: GDB l'exécutable deux fois

Pour ceux qui veulent voir un peu d'action, nous allons voir l'ASLR travail sur la TARTE exécutable et le changement des adresses à travers les pistes:

principal.c

#include <stdio.h>

int main(void) {
    puts("hello");
}

main.sh

#!/usr/bin/env bash
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
for pie in no-pie pie; do
  exe="${pie}.out"
  gcc -O0 -std=c99 "-${pie}" "-f${pie}" -ggdb3 -o "$exe" main.c
  gdb -batch -nh \
    -ex 'set disable-randomization off' \
    -ex 'break main' \
    -ex 'run' \
    -ex 'printf "pc = 0x%llx\n", (long  long unsigned)$pc' \
    -ex 'run' \
    -ex 'printf "pc = 0x%llx\n", (long  long unsigned)$pc' \
    "./$exe" \
  ;
  echo
  echo
done

La -no-pie, tout est ennuyeux:

Breakpoint 1 at 0x401126: file main.c, line 4.

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x401126

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x401126

Avant de commencer l'exécution, break main définit un point d'arrêt à 0x401126.

Puis, durant les deux exécutions, run s'arrête à l'adresse 0x401126.

L'un avec -pie, cependant, est beaucoup plus intéressant:

Breakpoint 1 at 0x1139: file main.c, line 4.

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x5630df2d6139

Breakpoint 1, main () at main.c:4
4           puts("hello");
pc = 0x55763ab2e139

Avant de commencer l'exécution, GDB prend juste un "dummy" de l'adresse qui est présent dans le fichier exécutable: 0x1139.

Après il commence toutefois, GDB intelligemment avis que le chargeur dynamique placé le programme dans un emplacement différent, et la première pause arrêté à 0x5630df2d6139.

Ensuite, le deuxième terme aussi intelligemment remarqué que l'exécutable déménage de nouveau, et fini par casser au 0x55763ab2e139.

echo 2 | sudo tee /proc/sys/kernel/randomize_va_space assure que l'ASLR est activée (par défaut dans Ubuntu 17.10): Comment puis-je désactiver temporairement l'ASLR (Address space layout randomization)? | Ask Ubuntu.

set disable-randomization off est nécessaire sinon GDB, comme son nom l'indique, désactive l'ASLR le processus par défaut de donner des adresses fixes à travers les pistes pour améliorer l'expérience de débogage: Différence entre gdb adresses et les "vraies" adresses? | Débordement De Pile.

readelf analyse

En outre, nous pouvons également observer que:

readelf -s ./no-pie.out | grep main

donne la réelle de l'exécution de la charge d'adresse (pc souligné l'instruction de 4 octets après):

64: 0000000000401122    21 FUNC    GLOBAL DEFAULT   13 main

tout:

readelf -s ./pie.out | grep main

donne juste un décalage:

65: 0000000000001135    23 FUNC    GLOBAL DEFAULT   14 main

En tournant l'ASLR off (avec randomize_va_space ou set disable-randomization off), GDB donne toujours main l'adresse: 0x5555555547a9, donc on en déduit que la -pie adresse est composée de:

0x555555554000 + random offset + symbol offset (79a)

TODO où est 0x555555554000 codées en dur dans le noyau Linux /glibc chargeur /où? Quelle est l'adresse de la section de texte de la TARTE exécutable déterminé dans Linux?

Minimale de l'assemblée exemple

Une autre chose de cool que nous pouvons faire est de jouer avec certains assemblée de code pour comprendre plus concrètement ce qu'TARTE moyens.

On peut le faire avec un Linux x86_64 autonome assemblée bonjour tout le monde:

principal.S

.text
.global _start
_start:
asm_main_after_prologue:
    /* write */
    mov $1, %rax   /* syscall number */
    mov $1, %rdi   /* stdout */
    mov $msg, %rsi  /* buffer */
    mov $len, %rdx /* len */
    syscall

    /* exit */
    mov $60, %rax   /* syscall number */
    mov $0, %rdi    /* exit status */
    syscall
msg:
    .ascii "hello\n"
len = . - msg

GitHub en amont

et il assemble et fonctionne bien avec:

as -o main.o main.S
ld -o main.out main.o
./main.out

Cependant, si nous essayons de les lier comme la TARTE avec:

ld --no-dynamic-linker -pie -o main.out main.o

puis lien échouera avec:

ld: main.o: relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC
ld: final link failed: nonrepresentable section on output

Parce que la ligne:

mov $msg, %rsi  /* buffer */

code en dur l'adresse de message dans le mov opérande, et n'est donc pas indépendant de la position.

--no-dynamic-linker est nécessaire, comme l'a expliqué à: Comment créer statiquement indépendant de la position de l'exécutable ELF dans Linux?

Si nous plutôt que de l'écrire dans une position indépendante:

lea msg(%rip), %rsi

puis TARTE lien fonctionne très bien, et GDB nous montre que l'exécutable est chargé à un autre emplacement dans la mémoire de tous les temps.

La différence ici est que lea codé l'adresse de msg par rapport à l'actuelle adresse du PC en raison de la rip syntaxe, voir aussi: Comment utiliser RIP Adressage Relatif, dans la version 64 bits de l'assemblée programme?

On peut aussi comprendre par le démontage des deux versions:

objdump -S main.o

qui donne respectivement:

e:   48 c7 c6 00 00 00 00    mov    $0x0,%rsi
e:   48 8d 35 19 00 00 00    lea    0x19(%rip),%rsi        # 2e <msg>

000000000000002e <msg>:
  2e:   68 65 6c 6c 6f          pushq  $0x6f6c6c65

Nous voyons donc clairement que lea a déjà le plein de corriger l'adresse de msg codé comme adresse actuelle + 0x19.

La mov version a cependant de définir l'adresse de 00 00 00 00, ce qui signifie qu'un transfert sera effectué il y a: Ce n'linkers faire? énigmatique R_X86_64_32S dans le ld message d'erreur est le type réel de déplacement qui est nécessaire et qui ne peut pas se produire dans la TARTE exécutables.

Une autre chose amusante que nous pouvons faire est de mettre le msg dans la section de données au lieu de .text avec:

.data
msg:
    .ascii "hello\n"
len = . - msg

Maintenant la .o assemble pour:

e:   48 8d 35 00 00 00 00    lea    0x0(%rip),%rsi        # 15 <_start+0x15>

de sorte que le RIP décalage est maintenant 0, et on devine qu'un transfert a été demandé par l'assembleur. Nous confirmons que avec:

readelf -r main.o

qui donne:

Relocation section '.rela.text' at offset 0x160 contains 1 entry:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000011  000200000002 R_X86_64_PC32     0000000000000000 .data - 4

donc clairement R_X86_64_PC32 est un PC par rapport à la réinstallation qui ld peut manipuler pour TARTE exécutables.

Cette expérience nous a enseigné que l'éditeur de liens se vérifie le programme peut être de la TARTE et de la marque en tant que telle.

Puis lors de la compilation avec GCC, -pie dit à GCC de générer indépendant de la position de l'assemblée.

Mais si nous écrire assemblée nous-mêmes, nous devons vérifier manuellement que nous avons réalisé de position de l'indépendance.

En ARMv8 aarch64, l'indépendant de la position bonjour tout le monde, peut être atteint à l' ADR, instruction.

Comment faire pour déterminer si un ELFE est indépendant de la position?

En cours d'exécution à travers GDB, certaines méthodes statiques sont mentionnés à:

• exécutable: https://unix.stackexchange.com/questions/89211/how-to-test-whether-a-linux-binary-was-compiled-as-position-independent-code/435038#435038
• bibliothèque: Comment puis-je dire, avec quelque chose comme objdump, si un fichier de l'objet a été construit avec -fPIC?

Testé sous Ubuntu 18.10.