Il est peut-être temps de réexaminer les microkernels à l’ère du matériel moderne

 (notes.hella.cheap)
1 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Les microkernels, autrefois peu pratiques en raison de leur surcoût élevé, pourraient redevenir une option réaliste grâce aux IOMMU désormais courantes et à la mémoire partagée
  • Isoler les pilotes et les sous-systèmes dans l’espace utilisateur permet de limiter l’impact des défaillances ou des attaques, et d’améliorer la sécurité, la fiabilité et la modularité
  • Dans les années 1980-1990, les processus en espace utilisateur ne pouvaient pas accéder directement aux périphériques, si bien que des opérations comme une lecture disque entraînaient à chaque fois des appels système et changements de contexte, des verrous et des copies mémoire
  • En exploitant les IOMMU et des files de commandes partagées, il est possible de gérer l’IPC asynchrone et l’accès aux périphériques sans changement de contexte, copie entre espaces d’adressage ni verrou sur le chemin normal
  • Des composants existants comme Xen, FreeBSD ou Linux DRM peuvent être réutilisés, ce qui réduit aussi la charge consistant à créer de zéro l’hyperviseur et les serveurs système

Structure des microkernels et effets de l’isolation

  • Un microkernel est une architecture de noyau qui exécute dans l’espace utilisateur les fonctionnalités autres que l’ordonnancement, la gestion de l’accès aux périphériques d’E/S et la communication interprocessus (IPC)
  • L’isolation des sous-systèmes apporte trois avantages
    • Sécurité : une vulnérabilité dans un pilote ne donne à un attaquant que les droits d’accès de ce sous-système ou de ce pilote, et non ceux de l’ensemble du système
    • Fiabilité : le crash d’un sous-système n’affecte que cette partie, et non tout le système
    • Modularité : cela allège la charge qui pèse sur l’équipe du noyau Linux, qui doit fusionner tous les pilotes matériels et examiner jusqu’au fonctionnement interne de chaque puce
  • Si Windows avait été un système à microkernel, le bug CrowdStrike aurait peut-être seulement interrompu la collecte de données de télémétrie de certains responsables de la sécurité IT

Les anciennes limites de performance et la solution apportée par l’IOMMU

  • Dans les anciens microkernels, les processus en espace utilisateur ne pouvaient pas accéder directement à certains périphériques, ce qui imposait des appels système et changements de contexte pour chaque opération, avec en plus des verrous coûteux et des copies mémoire
    • Mach a progressivement déplacé des processus en espace utilisateur dans le noyau à cause de problèmes de performance, jusqu’à finir par ressembler à un noyau monolithique classique
  • Aujourd’hui, les PC intègrent couramment depuis environ dix ans une IOMMU, qui, utilisée avec de la mémoire partagée, permet de supprimer complètement les changements de contexte sur le chemin normal lorsque le nombre de cœurs est suffisant
    • En acceptant un peu de latence, il est possible de supprimer presque tous les changements de contexte à l’échelle globale
    • Un ordonnanceur fondé sur les technologies de virtualisation peut être conçu sous une forme similaire à l’hyperviseur Xen
    • L’accès aux périphériques d’E/S est géré par le matériel IOMMU
  • L’IPC peut être implémentée en allouant un tampon partagé entre processus et en fournissant une opération atomique entière de compare-and-swap
    • Le tampon partagé est utilisé comme file de commandes sous forme de ring buffer, avec une mise à jour atomique des pointeurs de début et de fin
    • Sur le chemin normal, cela permet de transmettre des messages asynchrones sans changement de contexte, copie entre espaces d’adressage ni verrou, une méthode également largement utilisée dans les pilotes GPU

Organisation des bibliothèques et réutilisation du code existant

  • Dans un environnement où les processus sont des invités de VM, les bibliothèques partagées peuvent être liées au lancement du programme, et les fonctionnalités qui n’ont pas besoin de s’exécuter dans d’autres processus peuvent être traitées localement selon une approche exokernel
    • À l’heure où les applications distribuent chacune leurs propres composants de système d’exploitation à la manière d’Electron, les bibliothèques dupliquées en mémoire ne sont plus un problème aussi important qu’il y a 30 ans
  • Les principales briques nécessaires à l’implémentation existent déjà
    • Xen possède la plupart des fonctionnalités requises pour la couche d’hyperviseur
    • Comme avec Mach, on peut mettre en place des serveurs réseau et de système de fichiers tout en réutilisant du code FreeBSD
    • DRM reposant déjà sur des tampons de commandes asynchrones, le sous-système graphique de Linux peut être exécuté dans l’espace utilisateur
    • Pour plus de commodité, il est aussi possible d’exécuter le serveur d’affichage et le sous-système graphique dans le même processus

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • La raison pour laquelle Linux inclut tous les pilotes est qu’il n’existe pas d’API stable pour les modules noyau hors arborescence ; un micro-noyau n’est pas indispensable pour fournir une telle API

    • Les micro-noyaux n’empêchent pas non plus l’instabilité des API internes : ils ne font que déplacer la frontière entre processus
      Même en supposant que tous les pilotes Linux soient déplacés en espace utilisateur, je me souviens avoir vu sur LKML des critiques disant que les changements d’API internes deviendraient difficiles

  • Il me semble que les noyaux de la famille L4 sont réputés rapides. Je me demande aussi ce qu’il en est de Redox OS ou de Fuchsia

    • Les noyaux L4 peuvent être rapides, mais en pratique ils ne sont vraiment utilisables que dans des systèmes embarqués à configuration très fixe
      Genode prend en charge plusieurs noyaux, mais avec seL4 et consorts les performances sont ridiculement mauvaises. Quand des collègues ont essayé de démarrer une VM Linux, seul le 32 bits était pris en charge, et il fallait plusieurs minutes rien que pour arriver à mi-chemin du démarrage
      Si le fork Genode de NOVA microhypervisor est la plateforme par défaut, c’est parce qu’il fonctionne réellement et offre des performances suffisantes
    • D’après la documentation de Redox, l’assemblage des messages de requête implique toujours un changement de contexte, probablement pour une étape de validation
      Comme il utilise un tampon circulaire, si le destinataire est déjà en cours d’exécution sur un autre cœur, le second changement de contexte n’est peut-être pas nécessaire. Interpréter le message sans changement de contexte obligerait le destinataire à le valider, ce qui pourrait trop élargir la surface d’attaque, mais il semble possible d’atténuer cela avec une bibliothèque dynamique fournie par le noyau
      Je ne suis pas spécialiste, mais j’ai l’impression que l’article original omet plusieurs considérations importantes

  • QNX est connu comme un micro-noyau rapide ; je me demande ce qu’il a réussi à faire correctement

    • Le QNX que j’ai utilisé moi-même n’était pas rapide
      À l’époque, avec un ami, fascinés par l’élégance des micro-noyaux, et de QNX en particulier, nous avions implémenté un problème de traitement vidéo basé sur FireWire. Le code était simple et élégant, mais horriblement lent. Quand nous avons ajouté en environ 12 heures la prise en charge des transferts isochrones fondés sur DMA au pilote 1394 pour Linux, les performances se sont nettement améliorées, et cela a aussi dissipé les réticences de l’entreprise à utiliser Linux dans ses équipements de tri optique
      Les idéaux de QNX, des micro-noyaux et du passage de messages restent excellents, mais pour s’imposer largement, il faut réduire beaucoup plus le coût du transfert de données entre processus
      Aujourd’hui, je développe des applications web en Elixir et je bénéficie du même type d’isolation des processus que mettait en avant QNX. Comme ce ne sont pas des tâches aussi critiques en performances que le traitement optique, cela me convient, mais Elixir/BEAM a le même problème de copie des données

  • Même si Mach n’a pas réussi à rendre ses composants aussi totalement indépendants que prévu à l’origine, j’ai entendu dire qu’il n’était pas devenu pour autant un noyau monolithique ordinaire, et que son architecture apportait encore des avantages
    Dans un benchmark classique de liste de fichiers POSIX, où l’on appelle readdir() et stat() pour chaque entrée, un micro-noyau est forcément désavantagé. Mais avec une API de traitement par lots comme io_uring, qui réduit la fréquence des appels système, une latence élevée n’est peut-être pas un si gros point faible

    • Dans « on μ-Kernel Construction », 1995, Liedtke attribuait la lenteur de Mach à une forte empreinte cache, autrement dit à une conception qui n’était pas assez petite
      Linux non plus ne peut pas tenir le débit de ligne s’il effectue un appel système pour chaque paquet réseau. Le traitement par lots est important à la fois pour Linux et pour les micro-noyaux

  • Un entrant récent intéressant dans ce domaine est HongMeng, mais c’est malheureusement un logiciel propriétaire

  • Tant que le coût du déplacement des données ne diminuera pas fortement, d’au moins un ordre de grandeur, il semble difficile pour les micro-noyaux d’être suffisamment compétitifs
    En théorie, c’est élégant et propre, mais la réalité est complexe ; pour gérer cette complexité, le noyau doit peut-être lui aussi être complexe dans une certaine mesure

  • J’aime les architectures bien conçues, mais je pense que si Linux a atteint une position dominante, c’est aussi beaucoup grâce à des facteurs secondaires autres que la pure technique. J’aimerais lire un article qui analyse cela sous plusieurs angles