Un appel système est une entrée définie dans le noyau par laquelle le code de l'espace utilisateur demande une opération, par exemple ouvrir un fichier, mapper de la mémoire, créer un processus ou envoyer des données réseau. Le noyau valide les arguments, identifiants, états des objets et règles de sécurité avant d'effectuer la demande.
Kernel · Leçon 3
Appels système
Découvrez comment le code de l'espace utilisateur appelle les services du noyau Linux et comment examiner ces appels sans risque avec `strace`.
Bibliothèques et ABI des appels système
Les applications appellent couramment des fonctions de la bibliothèque C plutôt que d'écrire des instructions d'entrée propres à une architecture. Une fonction d'enveloppe prépare les registres et la mémoire conformément à l'ABI des appels système, entre dans le noyau et traduit le résultat selon les conventions du langage.
La relation n'est pas toujours d'une fonction à un appel système :
- une fonction de bibliothèque peut combiner plusieurs appels système ;
- certaines fonctions agissent entièrement dans l'espace utilisateur ;
- une fonction vDSO optimisée peut obtenir certaines données entretenues par le noyau sans transition de mode complète ;
- un appel système peut prendre en charge de nombreuses API de plus haut niveau.
Que fait une enveloppe d'appel système typique de libc ?
Entrer dans le noyau et en revenir
L'enveloppe place un numéro d'appel système et ses arguments dans des emplacements définis par l'architecture, puis exécute une instruction d'entrée comme syscall sur x86-64 ou svc sur AArch64. Le processeur passe à un point d'entrée privilégié configuré et le noyau distribue la demande.
Après l'opération, le noyau renvoie une valeur ou l'indication d'une erreur. Les enveloppes de la bibliothèque C renvoient couramment -1 et définissent la variable locale au thread errno en cas d'erreur. Les autres langages et environnements exposent différents types d'erreurs.
Décrire chaque entrée comme une « interruption logicielle » manque de précision sur les architectures actuelles ; les exceptions, instructions rapides d'appel système et appels superviseur mettent en œuvre des transitions contrôlées apparentées, mais différentes.
Qui valide les arguments et l'autorisation d'un appel système ?
Numéros et compatibilité
Les numéros d'appels système et conventions d'appel sont propres à l'architecture. Un même appel symbolique peut posséder un numéro ou une organisation des structures différents dans une autre ABI. Les versions du noyau peuvent ajouter des appels, tandis que les ABI stables de l'espace utilisateur cherchent à préserver les comportements existants.
Un processus non privilégié ne peut pas insérer arbitrairement de nouveaux gestionnaires dans la table des appels du noyau actif. Étendre l'interface exige du code dans le noyau et une conception soigneuse de l'ABI. Des fonctions comme seccomp peuvent filtrer les appels autorisés à un processus, mais ne créent pas de nouvelles implémentations dans le noyau.
Pourquoi une application doit-elle éviter de coder en dur les numéros d'appels système d'une autre architecture ?
Traçage avec `strace`
Tracez une commande simple et enregistrez sa sortie séparément :
$ strace -o trace.log -- ls
Suivez les processus enfants lorsque vous y êtes autorisé avec -f, ou limitez la sortie au moyen d'une expression comme :
$ strace -f -e trace=%file -o trace.log -- command
strace peut révéler des chemins, arguments, données issues de l'environnement, adresses réseau, fragments du contenu des fichiers et identifiants incorrectement passés comme arguments. Conservez les traces avec des permissions restrictives et supprimez-les selon les règles relatives aux données d'incident.
Qu'observe principalement strace ?
Interpréter prudemment les traces
Le traçage modifie le déroulement temporel et peut imposer un surcoût important. Un appel qui échoue peut être une sonde attendue et l'erreur finale visible peut découler d'une opération antérieure ou d'une règle de l'application. Décodez les descripteurs de fichiers, suivez les relations entre processus et rapprochez les résultats des journaux applicatifs.
Les permissions et règles de sécurité ptrace limitent les processus qu'il est possible de tracer. Ne vous attachez pas au processus d'un autre utilisateur ou à un processus de production sans autorisation ; la suspension et les changements temporels peuvent modifier le comportement du service.
L'échec d'un seul appel système dans une trace signifie-t-il nécessairement que l'application est cassée ?
Leçon terminée
Vous avez terminé Appels système
Vous savez maintenant suivre un appel système depuis l'API de bibliothèque jusqu'au travail validé du noyau.
Distinguer les fonctions de haut niveau de l'ABI des appels système.
Relier les instructions d'entrée de l'architecture à la distribution contrôlée dans le noyau.
Considérer les numéros et structures d'appels comme propres à l'architecture.
Employer des sorties
stracefiltrées tout en protégeant les données sensibles.Interpréter les échecs et le surcoût du traçage dans le contexte de l'application.
Conservez votre progression
Créez un compte gratuit pour enregistrer cette leçon et continuer sur n'importe quel appareil.
Créer un compte gratuit