Aux temps héroïques, le code auto-modifiable était fréquent. Ça consiste à écrire du code qui se modifie lui-même pendant l’exécution, pour faire des micro-optimisations qui tuent (en fait, surtout gagner une indirection par ci par là, mais à l’époque c’était pas négligeable).
Mais en fait, ça n’a pas complètement disparu : GCC, dans un cas précis, en génère d’ailleurs !
Fonctions imbriquées en C
Une fonction imbriquée en C est une fonction définie à l’intérieur d’une autre fonction. A quoi est-ce que ça sert ? Parfois, pour rendre votre code plus clair, vous définissez des fonctions qui ne sont utiles que dans une autre fonction. Il est donc débile de la rendre accessible depuis toutes les autres fonctions ! GNU CC vous autorise à écrire le code suivant (c’est une extension de GCC, ce n’est pas dans la norme C99) :
int f1() { int f2() { [...] } [...] f2(); [...] }
C’est bien joli, mais ça pose un problème. Regardez cet exemple (qui compile, n’hésitez pas à essayer) :
void f0(void (*f)()); long f1 (void) { long i = 0; void f2(void) { i++; } f0(f2); return i; } void f0(void (*f)()) { (*f)(); } int main() { return f1(); }
C’est tout à fait légal : f1 passe un pointeur vers f2 à f0, qui se charge d’appeler la fonction en paramètre. Le problème est que f2 modifie i. Or i est une variable locale de f1 (allouée sur la pile par f1). La distance entre ESP dans f2 et les variables locales de f1 sur la pile n’est pas connue : ici, f0 appelle directement f2, mais il pourrait appeler blop(f2) qui lui même appelerait f2. Il faut trouver un moyen de passer à f2 l’adresse du contexte de sa fonction parente.
Trampolines
Un papier (PDF) évoque ce problème pour le C++ (où les closures sont encore plus pratiques qu’en C, notamment lorsqu’on utilise des itérateurs). Il propose une solution élégante utilisant un trampoline. Dans l’article, il démontre la solution avec de l’assembleur 68000. Voici le code ci-dessus compilé pour x86, sans optimisation histoire de garder le code le plus proche possible du C.
.file "t5.c" .text .type f2.0, @function f2.0: pushl %ebp movl %esp, %ebp subl $4, %esp movl %ecx, -4(%ebp) movl -4(%ebp), %ecx incl -4(%ecx) leave ret .size f2.0, .-f2.0 .globl f1 .type f1, @function f1: pushl %ebp movl %esp, %ebp subl $40, %esp leal -24(%ebp), %eax addl $0, %eax andl $-1, %eax movl $f2.0, %ecx leal 10(%eax), %edx subl %edx, %ecx movl %ecx, %edx movb $-71, (%eax) leal -8(%ebp), %ecx movl %ecx, 1(%eax) movb $-23, 5(%eax) movl %edx, 6(%eax) movl $0, -12(%ebp) leal -24(%ebp), %eax addl $0, %eax andl $-1, %eax movl %eax, (%esp) call f0 movl -12(%ebp), %eax leave ret .size f1, .-f1 .globl f0 .type f0, @function f0: pushl %ebp movl %esp, %ebp subl $8, %esp movl 8(%ebp), %eax call *%eax leave ret .size f0, .-f0 .globl main .type main, @function main: pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp movl $0, %eax subl %eax, %esp call f1 leave ret .size main, .-main .section .note.GNU-stack,"x",@progbits .ident "GCC: (GNU) 3.3.5 (Debian 1:3.3.5-8)"
Un trampoline, c’est un petit bout de code qui va mettre dans registre (ici ECX, je ne sais pas quelle est la convention exactement) l’adresse de l’environnement de la fonction parente. Dans le code de f2, on voit qu’on incrémente -4(%ecx) pour incrémenter i. Ce petit bout de code est généré sur la pile par f1 avant d’appeler f0. Le code qui génère le code est entre “subl $40, %esp” et “call f0”, en gros. Et mon débogueur me dit que le code généré ressemble à :
Dump of assembler code from 0xbffff930 to 0xbffffa30: 0xbffff930: mov $0xbffff940,%ecx 0xbffff935: jmp 0x8048354
Quand f0 fera son call, il appellera une adresse de la pile sans le savoir. Et quand f2 retournera, elle retournera directement dans f0.
C’est trop beau, il doit bien y avoir un problème qqpart …
Hé oui. La pile exécutable, c’est un problème : c’est la base de l’exploitation de beaucoup de trous de sécurité. Du coup, des systèmes essayent de rendre la pile non exécutable. C’est le cas de OpenBSD avec W^X, ou de Linux avec Exec-shield (PDF). Comment faire pour continuer à autoriser les trampolines, alors ? Et bien c’est tout simple. Sous linux, l’en-tête ELF des binaires contient un flag indiquant si ce programme a besoin que la pile soit exécutable. Avec l’exécutable du code de tout à l’heure :
***lucas@blop:~% readelf -l t5 | grep STACK STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Tandis qu’avec un autre exécutable (notez le RW au lieu du RWE) :
***lucas@blop:~% readelf -l t3 | grep STACK STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
C’est un flag ajouté par GCC.
Bravo si vous avez lu jusque là ;)
