Connexion Premium

L’architecture mklinux fait tourner des noyaux Linux en parallèle sans virtualisation

Ça pousse plus vite ?

L’architecture mklinux fait tourner des noyaux Linux en parallèle sans virtualisation

Illustration : Flock

Vous avez toujours rêvé de vous passer de la virtualisation pour faire tourner des services complètement différents en parallèle sur une même machine ? C’est ce que propose mklinux en permettant de faire tourner des noyaux Linux en parallèle.

Le responsable de l’entreprise Multikernel Technologies, Cong Wang, a annoncé, la semaine dernière sur la mailing list du noyau Linux, la sortie de son projet mklinux v7.0-mk2 (disponible sur GitHub). Celui-ci permet d’exécuter plusieurs noyaux sur un même ordinateur, sans hyperviseur, donc sans virtualisation. Chacun d’entre eux gère réellement le matériel qu’il utilise.

« L’arborescence est basée sur la version 7.0 [du noyau Linux]. Avec CONFIG_MULTIKERNEL=n, elle se compile et se comporte exactement comme la version 7.0 », précise-t-il.

Chaque noyau s’exécute sur son propre matériel

Le principe est que mklinux (ou multikernel) lance un premier noyau qui gère un certain nombre de processeurs, de la mémoire et des périphériques. Ce premier noyau divise ces ressources « en instances et démarre un noyau dérivé dans chaque instance via la fonction kexec_file_load() », explique Cong Wang.

« Chaque noyau dérivé s’exécute en mode natif sur ses propres processeurs, sa propre mémoire physique et ses propres périphériques. Rien n’est émulé et rien n’est intercepté ; la seule chose partagée est ce que vous choisissez de partager », ajoute le responsable du projet.

Optimisation du traitement et de l’exposition aux risques

L’idée de multikernel est de proposer une véritable isolation au niveau du noyau « avec des performances proches de celles d’un système « bare-metal » et une allocation dynamique des ressources, sans la surcharge d’un hyperviseur », comme l’explique la FAQ du projet. Cela doit permettre une optimisation de la vitesse de traitement et de l’exposition aux risques.

La promesse de cette architecture est que le blocage d’un noyau, une faille de sécurité le touchant ou un kernel panic n’aient aucune conséquence sur les autres systèmes qui tournent en parallèle.

Le concepteur explique dans son message avoir validé par des tests : « Des instances ont été lancées, arrêtées, reconfigurées et relancées dans le cadre de longues boucles de test […] ; un plantage dans un noyau n’affecte pas les autres, et il est confirmé que chaque processeur attribué à une instance est remis en veille sur l’hôte avant d’être réutilisé ».

Et, « en comparant aux machines virtuelles, il n’y a pas de chemin de sortie de la VM, pas de deuxième niveau de tables des pages et pas de modèle de périphérique », ajoute Cong Wang.

Dans son annonce, il donne quelques comparaisons de performances. Ainsi, face à une machine virtuelle KVM, multikernel est de 1,07 fois (fork + sortie) à 2,5 fois plus rapide (changement de contexte), avec une bande passante mémoire et une latence équivalentes :

Pour l’instant, multikernel fonctionne sur architecture x86_64, même si l’annonce sous-entend que le projet ne s’y limitera pas. D’ailleurs, sur son site, l’entreprise vante déjà des solutions pour ARM ou RISC-V.

En pratique, quelles utilisations cible le projet ? Multikernel Technologies propose déjà plusieurs offres de service destinées aux entreprises visant la mise en place de clouds privés sans hyperviseur, le sandboxing d’agents IA et la mise à jour du noyau sans avoir à redémarrer la machine.

Commentaires (10)

votre avatar
C'est intéressant mais comment ces noyaux gèrent des ressources uniques type périph matériel en tout genre, la DMA, l'ACPI, le catch des interruptions etc. ?
votre avatar
Il y a un noyau à part (device-kernel ) qui les possède, les autres noyaux ont des drivers virtuels. suivre le lien pour plus de détails.
votre avatar
Driver virtuels qui doivent communiquer avec le device-kernel, et donc un moyen de sortir par là, même si la surface d'attaque doit être bien plus faible qu'avec KVM. J'imagine aussi qu'à moins d'utiliser que très peu de noyaux (un par CPU physique, il faut du multi-socket), les caches CPUs se retrouvent partagés, un autre moyen d'extraire des informations.
votre avatar
Je pense que l'idée est qu'il n'y a pas de sortie parce qu'il n'y a rien "autour". Y'a un autre kernel à côté (au moins 1). A côté, pas autour...

Dans ce contexte la cible devient les autres kernels.
votre avatar
J'ai bien du mal a voir la différence (dans le cas d'usage) avec ce que font les micro-noyaux comme exécutés par firecracker ou cloudhypervisor , si les ressources matérielles sont effectivement virtualisées.

Par certains coté ça me rappelle un peu Jailhouse, mais le seul cas "intéressant" que je vois c'est sur une plateforme ou ya pas les instructions de virtualisation , sinon, comme tu dis il y a forcément un scheduler, un partitionnement mémoire, une conccurence sur les accès I/O...

Même pour un kernel dédié "anticheat" comme le propose zuxupi, quel gain par rapport à une microVM ?
votre avatar
Ce qui n'est pas bien clair pour moi, c'est que pour avoir une séparation "plus haut", il faut bien utiliser des conteneurs ou quelque chose comme ça, non ? Sinon, j'ai peut-être 2 noyaux mais un seul disque dur avec une seule arborescence /, /etc, /usr, ... et si j'écris dans /usr/bin/, les 2 noyaux et leurs arborescence de PID verront la modification. Comment se gère alors cette cohérence de ce cloisonnement qui va des noyaux jusqu'aux environnements d'exécution ?
votre avatar
Tu as un noyau principal qui possède le disque. Les autres n'ont pas de disque (sauf si tu leur en donne un explicitement, mais c'est alors un disque différent) ; il bootent sur une image docker par défaut.
votre avatar
The Linux Experiment a mentionne une autre idee d'utilisation potentielle : lancer un noyau dedie au jeu video qui contienne un anti-cheat noyau.
votre avatar
Zut, j'ai cru l'espace d'un instant que j'allais pouvoir ressortir mon vieux PowerMac 7100 pour faire tourner une nouvelle version de Mk Linux. :phiphi:
votre avatar
J'avoue que je ne comprends pas bien l'intérêt par rapport à du LXC ou du Podman rootless... Quelqu'un saurait m'expliquer ? J'imagine qu'il est question de cloisonnement, mais à un moment si la paranoïa est trop forte, peut-être qu'il faut juste du matériel dédié... non ?