Contexte exemple¶

Réaliser des appels système peut être lent. Dans les systèmes 32 bits x86, vous pouvez déclencher une interruption logicielle (int $0x80) pour indiquer au noyau que vous voulez faire un appel système. Cependant, cette instruction est coûteuse : elle passe par tous les chemins complets de traitement des interruptions dans le microcode du processeur ainsi que dans le noyau. Les nouveaux processeurs ont des instructions plus rapides (mais non rétrocompatibles) pour initier les appels système. Plutôt que forcer la bibliothèque C à vérifier si cette fonctionnalité est disponible au moment de l’exécution, la bibliothèque C peut utiliser les fonctions fournies par le noyau dans le vDSO.

Remarquez que cette terminologie peut être source de confusion. Sur les systèmes x86, la fonction vDSO utilisée pour déterminer la méthode préférée pour réaliser un appel système est appelée « __kernel_vsyscall » alors que sous x86_64, le terme « vsyscall » se réfère aussi à une façon obsolète de demander au noyau l’heure ou le processeur sur lequel est l’appelant.

Un appel système fréquemment utilisé est gettimeofday(2). Cet appel système est appelé à la fois directement par les applications en espace utilisateur et indirectement par la bibliothèque C. Remarquez que les horodatages, boucles temporelles ou scrutations — ont tous fréquemment besoin de savoir l’heure exacte. Ce n’est pas non plus un secret — n’importe quelle application dans n’importe quel mode (superutilisateur ou utilisateur normal) aura la même réponse. Alors le noyau s’arrange pour que les informations nécessaires pour répondre à cette question soient placées dans la mémoire accessible au processus. Ainsi un appel de gettimeofday(2) est transformé d’un appel système en un appel normal de fonction, avec peu d’accès mémoire.

Trouver le vDSO¶

L’adresse de base du vDSO (s’il existe) est passée par le noyau à tous les programmes dans le vecteur auxiliaire initial (consultez getauxval(3)) à l’aide de l’indicateur AT_SYSINFO_EHDR.

Vous ne devez pas supposer que le vDSO est projeté à un endroit particulier de la projection en mémoire de l’utilisateur. L’adresse de base sera normalement aléatoire au moment de l’exécution à chaque fois qu’une nouvelle image de processus est créée (au moment de execve(2)). C’est ainsi pour des raisons de sécurité, afin d’éviter les attaques de « retour vers libc ».

Pour certaines architectures, un indicateur AT_SYSINFO est aussi présent. Il n’est utilisé que pour localiser le point d’entrée vsyscall et est souvent omis ou défini à 0 (signifiant qu’il n’est pas disponible). Cet indicateur est un rappel du fonctionnement initial de vDSO (consultez Historique ci-dessous) et son utilisation devrait être évitée.

Format de fichier¶

Puisque le vDSO est une image ELF complète, vous pouvez y rechercher des symboles. Cela permet d’ajouter de nouveaux symboles avec les versions de noyau plus récentes et permet à la bibliothèque C de détecter les fonctionnalités disponibles au moment de l’exécution lors de l’exécution sous différentes versions de noyau. D’habitude, la bibliothèque C fera la détection lors du premier appel puis mettra en cache le résultat pour les appels suivants.

Tous les appels sont aussi versionnés (en utilisant le format de version GNU). Cela permet au noyau de mettre à jour la signature de fonction sans casser la rétrocompatibilité. Cela signifie modifier les arguments acceptés par la fonction et la valeur de retour. Ainsi, lors de la recherche de symboles dans le vDSO, vous devez toujours inclure la version pour correspondre à l’ABI attendue.

Typiquement, le vDSO suit la convention de nommage de préfixer tous les symboles par « __vdso_ » ou « __kernel_ » afin de les distinguer des autres symboles standards. Par exemple, la fonction « gettimeofday » est nommée « __vdso_gettimeofday ».

Utilisez les conventions d’appel C standard pour appeler n’importe laquelle de ces fonctions. Pas la peine de vous embêter avec les registres bizarres ou les comportements de pile.

Source¶

Lors de la compilation du noyau, le code vDSO est compilé et lié automatiquement. Il se trouve souvent dans le répertoire spécifique à l’architecture :

find arch/$ARCH/ -name '*vdso*.so*' -o -name '*gate*.so*'

Noms vDSO¶

Le nom du vDSO dépend des architectures. Il est souvent visible dans des endroits comme la sortie de ldd(1) de la glibc. Le nom exact ne devrait affecter aucun code, donc pas la peine de le coder en dur.

strace(1), seccomp(2) et le vDSO¶

Lors du suivi des appels système avec strace(1), les symboles (appels système) qui sont exportés par le vDSO n’apparaîtront pas dans la sortie du suivi. De même, ces appels système ne seront pas visibles par les filtres seccomp(2).

Fonctions ARM¶

Le tableau suivant indique les symboles exportés par le vDSO.

De plus, le portage ARM a une page de code pleine de fonctions utilitaires. Puisque ce n’est qu’une page de code brut, aucune information ELF n’existe pour faire la recherche de symboles ou le versionnage. Elle fournit cependant une prise en charge pour plusieurs versions.

Pour des renseignements sur cette page de code, mieux vaut consulter la documentation du noyau puisqu’elle est extrêmement détaillée et couvre tous ce que vous devez savoir : Documentation/arm/kernel_user_helpers.rst.

Fonctions aarch64¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions bfin (Blackfin) (portage supprimé dans Linux 4.17)¶

Comme ce processeur n’a pas d’unité de gestion mémoire (MMU), il ne définit pas de vDSO au sens usuel. À la place, il projette au démarrage quelques fonctions brutes à un endroit spécifique de la mémoire. Les applications en espace utilisateur appellent ensuite directement dans cette zone. Aucune mesure de rétrocompatibilité n’est prise à part en sniffant les codes opératoires bruts, mais comme il s’agit d’un processeur embarqué, il peut s’en sortir impunément – certains formats d’objet qu’il exécute ne sont même pas basés sur ELF (ils sont bFLT/FLAT).

Pour des renseignements sur cette page de code, mieux vaut consulter la documentation publique :
http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:fixed-code

Fonctions mips¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions ia64 (Itanium)¶

Le tableau suivant indique les symboles exportés par le vDSO.

Le portage Itanium est un peu périlleux. En plus du vDSO ci-dessus, il a aussi des « appels système légers » (aussi appelés « appels système rapides » ou « fsys »). Ils peuvent être appelés à l’aide de l’assistant vDSO __kernel_syscall_via_epc. Les appels système indiqués ici ont la même sémantique que si vous les appeliez directement à l’aide de syscall(2), donc consultez la documentation adéquate pour chacun d’entre eux. Le tableau suivant indique les fonctions disponibles par ce mécanisme.

Fonctions parisc (hppa)¶

Le portage parisc à une page de code pleine de fonctions utilitaires appelée une page passerelle. Plutôt que d’utiliser l’approche classique du vecteur auxiliaire ELF, il passe l’adresse de la page au processus à l’aide du registre SR2. Les permissions sur la page sont telles qu’exécuter simplement ces adresses s’exécute automatiquement avec les droits du noyau et pas en espace utilisateur. C’est ainsi afin de correspondre au mode de fonctionnement HP-UX.

Puisque ce n’est qu’une page de code brut, aucune information ELF n’existe pour faire la recherche de symboles ou le versionnage. Appelez simplement l’adresse adéquate à l’aide de l’instruction de branche, par exemple :

ble <offset>(%sr2, %r0)

Fonctions ppc/32¶

Le tableau suivant indique les symboles exportés par le vDSO. Les fonctions marquées avec un * ne sont disponibles que si le noyau est PowerPC64 (64 bits).

Avant Linux 5.6, les horloges CLOCK_REALTIME_COARSE et CLOCK_MONOTONIC_COARSE ne sont pas prises en charge par les interfaces __kernel_clock_getres et __kernel_clock_gettime. Le noyau a recours à l’appel système réel.

Fonctions ppc/64¶

Le tableau suivant indique les symboles exportés par le vDSO.

Avant Linux 4.16, les horloges CLOCK_REALTIME_COARSE et CLOCK_MONOTONIC_COARSE ne sont pas prises en charge par les interfaces __kernel_clock_getres et __kernel_clock_gettime. Le noyau a recours à l’appel système réel.

Fonctions riscv¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions s390¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions s390x¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions sh (SuperH)¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions i386¶

Le tableau suivant indique les symboles exportés par le vDSO.

Fonctions x86-64¶

Le tableau suivant indique les symboles exportés par le vDSO. Tous ces symboles sont aussi disponibles sans le préfixe « __vdso_ », mais vous devriez les ignorer et vous cantonner aux noms suivants.

Fonctions x86/x32¶

Le tableau suivant indique les symboles exportés par le vDSO.

Historique¶

Le vDSO n’était à l’origine qu’une seule fonction — le vsyscall. Dans les anciens noyaux, ce nom pourrait être vu dans une projection en mémoire de processus à la place de « vdso ». Le temps passant, les gens ont réalisé que ce mécanisme était un excellent moyen pour passer plus de fonctionnalités à l’espace utilisateur, il a donc été reconçu en tant que vDSO au format actuel.