Les codes fantastiques : lib et introspection

Magazine
Marque
GNU/Linux Magazine
Numéro
260
Mois de parution
novembre 2022
Spécialité(s)


Résumé

Pour commencer cette série sur les codes fantastiques, nous allons faire un petit tour dans la page de manuel de dlopen et (re)découvrir une forme d’introspection au niveau bibliothèque partagée.


Body

Sous Linux, le chargement à l’exécution de bibliothèque partagée repose sur la libdl, et l’appel à la fonction dlopen. L’usage classique est de récupérer un pointeur vers une structure opaque représentant la bibliothèque ouverte par l’appel :

void* handle = dlopen(filename, flag);

avant de rechercher un symbole en passant ce pointeur et le nom du symbole recherché à la fonction dlsym :

void* sym = dlsym(handle, "mysymbol");

Il existe cependant un autre mode d’utilisation de dlsym qui repose sur un handle réservé, RTLD_DEFAULT, et qui permet de rechercher un symbole parmi les bibliothèques déjà ouvertes par le processus en cours. Cette fonctionnalité, qui est une extension GNU, peut s’avérer très utile pour avoir un comportement conditionnel suivant l’environnement dans lequel on s’exécute.

Jetons un œil au fichier suivant, destiné à être compilé en tant que bibliothèque partagée :

#include <stdio.h>
#include <dlfcn.h>
 
__attribute__((constructor)) void check_in_python() {
  if (dlsym(RTLD_DEFAULT, "Py_GetVersion()"))
    puts(Py_GetVersion());
  else
    puts("not in a python env");
}

Lorsque la bibliothèque est chargée, la fonction check_in_python va s’exécuter (elle est marquée comme constructor). Si le processus en cours ne contient aucune bibliothèque définissant le symbole Py_GetVersion, elle affichera « not in a python env ». Mais si elle est chargée depuis un processus Python, comme dans le cas suivant, elle affichera des informations de version.

>>> import ctypes
>>> ctypes.CDLL("./libpy.so") # libpy.so est notre petite bibliothèque partagée

Par exemple, on retrouve ce comportement dans le projet LLVM, pour détecter si le binaire dans lequel une bibliothèque est chargée a été compilé depuis le langage Swift :

static void InitializeSwiftDemangler() {
  swift_demangle_f = (swift_demangle_ft)dlsym(RTLD_DEFAULT, "swift_demangle");
}

En bonus, notons que l’on peut atteindre un résultat semblable, plus rapide, mais moins portable en utilisant les weak symbols :

#include <stdio.h>
__attribute__((weak)) const char* Py_GetVersion();
__attribute__((constructor)) void check_in_python() {
  if (Py_GetVersion)
    puts(Py_GetVersion());
  else
    puts("not in a python env");
}

Cette fois, l’astuce repose sur le comportement par défaut d’un symbole marqué weak et non initialisé : il est mis à zéro. Sauf que si ce symbole est défini dans le processus chargé, il prendra la valeur de ce symbole, ce qui permet de détecter la présence de ce dernier sans passer par la libdl : c’est le dynamic loader qui se charge du travail au chargement du binaire (ce n’est donc pas strictement équivalent à la libdl qui effectue le test au moment où le code est exécuté).



Article rédigé par

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous