Doctorat en Electronique Numérique

Description du laboratoire et de son environnement immédiat de recherche (équipe) : Le laboratoire LIG est incontournable dans le domaine de la recherche en informatique, tant au niveau local, national qu’international. Il compte près de 450 chercheurs, enseignants-chercheurs, doctorants et personnels d’appui à la recherche. L’ambition du LIG est de contribuer au développement des aspects fondamentaux de l’informatique (modèles, langages, méthodes, algorithmes) et de favoriser la synergie entre les enjeux conceptuels, technologiques et sociétaux associés à cette discipline. Le LIG est organisé autour de cinq axes de recherche thématiques, dont les Systèmes Distribués, le Calcul Parallèle et les Réseaux, qui regroupent cinq équipes. Les travaux de thèse se dérouleront au sein du projet ERODS du LIG (erods.imag.fr), sous la direction d’Alain TCHANA. L’équipe mène des recherches sur la construction et l’administration de systèmes d’exploitation et de systèmes distribués. Elle s’intéresse particulièrement aux mécanismes de virtualisation, ainsi qu’à l’autonomie et à la robustesse des systèmes. Description du poste : Au cours de la dernière décennie, l’avancée exponentielle du numérique dans nos sociétés (santé, politique, sécurité, transports, divertissement, etc.) a conduit à l’émergence d’une grande variété d’applications et de plateformes matérielles que les systèmes d’exploitation (OS ) doit s’adapter.

Compte tenu de la diversité de ces environnements, les systèmes d’exploitation monolithiques traditionnels (tels que Linux, FreeBSD, Mac et Windows) sont devenus difficiles à maintenir, vulnérables et sous-optimaux. Pour illustrer ce défi de recherche, considérons le sous-système polyvalent de récupération de mémoire de Linux, kswapd, qui entre en jeu dans des situations de pression mémoire. kswapd donne la priorité aux pages les moins récemment utilisées (LRU) pour l’expulsion de la RAM. Cependant, lorsque cette stratégie rencontre une application de lecteur multimédia qui lit un octet puis continue sans le revoir, kswapd fonctionne mal. Pour une telle application, les pages les plus récemment utilisées (MRU) doivent d’abord être expulsées de la RAM. La personnalisation de kswapd présente un défi et nécessite un redémarrage de la machine. Le problème fondamental des systèmes d’exploitation populaires réside dans leur nature monolithique, qui impose l’exécution de tous les services dans l’espace du noyau, ce qui rend la personnalisation complexe. Comment les services des systèmes d’exploitation monolithiques peuvent-ils être personnalisés et déployés facilement et rapidement sans interruption ?

Renouveau de l’approche micro-noyau Le besoin de personnalisation et de rapidité (déploiement rapide) des services du système d’exploitation est devenu de plus en plus urgent au cours de la dernière décennie. Cela est attribué à l’émergence de nombreuses nouvelles applications (IA, moteurs de recherche, magasins de valeurs clés, machines virtuelles, etc.) et de pédales d’accélération matérielle (NUMA, processeurs asymétriques, GPU, TPU, PIM, NVRAM, etc.). Les politiques génériques dans un système d’exploitation monolithique deviennent insatisfaisantes (en termes de performances) pour tous les environnements (combinaisons d’applications et de matériel). Deux approches sont actuellement explorées pour personnaliser les services du système d’exploitation. La première approche, le hot kernel hooking, consiste à faire évoluer le système d’exploitation monolithique en injectant du code au moment de l’exécution. Cette approche repose sur deux hypothèses : la présence de hooks dans l’OS et la présence d’une machine virtuelle dans l’OS capable d’exécuter de manière sécurisée le code injecté. Sous Linux, la plupart des contributions sont basées sur le framework BPF. On peut par exemple citer le Sirop. La deuxième approche est simplement un retour aux micro-noyaux. Cependant, au lieu de développer des micro-noyaux à partir de zéro, les chercheurs sont pragmatiques : ils tentent de transformer le système d’exploitation Linux monolithique en un micro-noyau. Cette stratégie garantit l’adoption du système d’exploitation résultant car il restera un système d’exploitation Linux, capable d’exécuter des applications existantes sans aucune modification. Nous soutenons l’approche micronoyau car la première présente plusieurs limites. Premièrement, les frameworks d’injection de code sous Linux imposent de fortes contraintes sur les structures de contrôle et le domaine d’accessibilité du code injecté. Par exemple, BPF interdit les boucles infinies et le code BPF ne peut pas accéder ou modifier les structures de données manipulées par le système d’exploitation. Deuxièmement, cette approche repose sur la disponibilité de hooks dans les services du système d’exploitation que l’on souhaite personnaliser. En résumé, cette approche ne permet pas de rédiger des politiques élaborées.
L’objectif de MiLK est de fournir un standard/modèle Linux sur lequel les développeurs s’appuieront pour externaliser les services Linux dans l’espace utilisateur en suivant l’approche du micro-noyau. L’innovation majeure de MiLK est l’introduction d’une nouvelle abstraction appelée MilkT (pour MiLK Task), un peu comme Process et Thread conçus pour l’exécution de services du système d’exploitation dans l’espace utilisateur. En effet, les services OS ont des besoins différents par rapport aux services applicatifs pour lesquels les concepts Thread et Process ont été conçus. Nous avons identifié plusieurs limites à ces deux concepts, les plus significatives étant :

• L’espace d’adressage virtuel du système d’exploitation lorsqu’il se trouve dans l’espace du noyau est mappé de manière contiguë dans la mémoire physique, ce qui facilite la traduction des adresses. En utilisant le concept de processus classique pour externaliser les services du système d’exploitation, cette optimisation n’est plus garantie.
• Certains services du système d’exploitation partagent ou agissent sur les mêmes structures de données. C’est le cas par exemple du planificateur et du gestionnaire de mémoire, qui manipulent la structure struct_task sous Linux. Cela est impossible lorsque l’abstraction des processus est utilisée pour les externaliser dans l’espace utilisateur. L’utilisation de l’abstraction Thread résoudrait ce problème, mais introduirait également le problème de la tolérance aux pannes des services les uns par rapport aux autres. Le lecteur pourrait penser que l’abstraction orbitale récemment développée par Jing et al [orbit.osdi.22] suffirait. Ce n’est pas vrai puisque l’orbite a été inventée pour représenter des tâches auxiliaires d’autres tâches principales. Dans le contexte de MiLK, tous les services du système d’exploitation sont tout aussi importants.
• L’utilisation d’appels système ou de systèmes de fichiers /proc ou /sys comme le font les processus classiques entraînerait une surcharge considérable en raison du fait que les services du système d’exploitation communiquent largement.
• Compte tenu de leur caractère critique, les services du système d’exploitation dans l’espace utilisateur doivent appliquer nativement des politiques de tolérance aux pannes, ce qui n’est pas nécessaire pour les processus applicatifs. L’objectif de la thèse de doctorat est d’étudier cet aspect de MiLK.