Présentation

Ginux est un noyau configurable qui s’exécute comme un processus Linux ordinaire. Il place un contrat versionné entre les charges de travail gérées et le noyau hôte, ce qui permet de restreindre explicitement les appels système disponibles. Initialement développé en Rust comme noyau bootable via UEFI et capable de lancer un environnement Rocky Linux 10, le projet a migré vers le mode « userspace kernel » après la préservation du code source sur les branches bootable-kernel et le tag bootable-kernel-final. Cette transition repose sur la capacité d’un agent d’IA, guidé par un humain, à produire un prototype fonctionnel.

Architecture et mécanisme de contrat

Le processus Ginux s’insère sous le systemd du système hôte (PID 1) et supervise les programmes x86‑64 natifs. Avant tout effet sur le système, chaque appel système passe par un répartiteur central qui consulte le contrat d’instance. Trois issues sont possibles : émulation (réponse générée à partir d’un état interne), médiation (validation puis exécution d’une opération restreinte) ou refus (renvoi d’une erreur compatible Linux ou terminaison du processus). Le contrat décrit les processus virtuels, les descripteurs, les périphériques assignés et les vues limitées de /proc, /sys, cgroup v2, montages et espaces de noms.

Sécurité et modèle de confinement

Ginux intègre un interpréteur x86‑64 orienté sécurité et un backend ptrace natif équilibré, garantissant que les appels système sont interceptés de façon fiable. La configuration d’instance est strictement versionnée et stockée dans un OCI root à empreinte fixe, avec un index de système de fichiers immuable et une superposition bornée. Les modèles de processus, d’identifiants, de signaux, de synchronisation, de minuteries et d’événements sont tous gérés par Ginux, ce qui élimine la dépendance directe au noyau hôte. Le réseau reste partagé mais chaque requête réseau est médiée, limitant les ouvertures de ports non autorisées. Cette granularité permet de créer des environnements où un agent d’IA ne voit que les ressources explicitement allouées, par exemple la lecture de l’heure et l’inspection de ses propres processus, tout en bloquant les modifications d’horloge ou l’accès au système de fichiers hôte.

Limites et perspectives

Le projet ne prétend pas offrir une compatibilité Linux complète ; il s’appuie sur une image Rocky Linux 10 « pinned » qui atteint multi-user.target et accepte les mises à jour via les dépôts officiels. Les métriques de performance, les tests d’évasion et la couverture des appels système restent en cours d’évaluation dans les gates HDAE. En outre, la reproduction de l’écosystème Linux (processus de développement, communauté, alignement matériel) n’est pas l’objectif, ce qui limite l’usage de Ginux à des scénarios de confinement ciblés plutôt qu’à un remplacement du noyau. La recherche ouvre néanmoins la voie à des frontières de vérification explicites entre les appels système, les ioctl, les périphériques et les espaces de noms, offrant un terrain d’expérimentation pour des sandboxes de prochaine génération.

Host Linux kernel
  `- host systemd (real PID 1)
       `- ginux (ordinary trusted host process)
            `- instance contract
                 |- virtual processes and identities
                 |- virtual descriptors and kernel views
                 |- assigned devices and resources
                 `- managed Rocky Linux userspace
                      `- instance systemd (virtual PID 1)