Un chercheur de Google affirme que la conception du noyau de Windows NT éclipse toujours Linux

Résumé :

Laurie Kirk, une chercheuse qui a travaillé comme ingénieur inverse chez Microsoft pendant quatre ans et travaille maintenant chez Google, a récemment relancé le débat qui dure depuis des décennies entre Windows et Linux. Elle a déclaré publiquement que le noyau de Windows NT est toujours un « miracle d'ingénierie » du point de vue de la conception technique, et éclipse même Linux à bien des égards.

Kirk a souligné que ce qu'elle admirait n'était pas le menu Démarrer, Copilot ou les publicités de Windows 11, mais l'architecture sous-jacente du noyau NT de Windows. Elle estime que NT a établi dès le début un modèle objet et un système de sécurité relativement complets, tandis que Linux a progressivement ajouté des mécanismes de sécurité tels que des capacités, des espaces de noms et SELinux sur la base d'Unix traditionnel, de sorte qu'il semble globalement plus dispersé.

Kirk a déclaré sur les plateformes sociales que si vous donnez la description la plus simple du point de vue d'un programmeur, NT est plus proche d'une conception « orientée objet » et dispose dès le départ d'un modèle de sécurité très solide ; en revanche, de nombreuses fonctionnalités de sécurité de Linux ont été progressivement ajoutées par la suite. Elle pense que si un noyau de système d'exploitation orienté vers l'avenir est conçu à partir de zéro aujourd'hui, la forme finale ne ressemblera probablement pas à Linux, mais sera plus proche de NT, et pourrait même être similaire à certaines branches de BSD.

Windows NT constitue en fait la base technique de toutes les principales versions de Windows depuis 1993, y compris Windows 11 d'aujourd'hui. Microsoft a embauché Dave Cutler en 1988, qui était auparavant responsable du développement du système d'exploitation VMS chez DEC. Selon Microsoft, une petite équipe d'anciens ingénieurs DEC dirigée par Cutler a passé environ six mois à développer la spécification avant de commencer réellement à écrire du code. Les objectifs initiaux comprenaient la portabilité, la prise en charge de plusieurs processeurs et une certification de sécurité de niveau C2.

Dave Plummer, ingénieur Microsoft à la retraite, a également participé à la discussion. Il a souligné que NT n'est pas la première fois que Cutler conçoit un noyau de système d'exploitation à partir de zéro. Il a déjà participé à RSX-11M et VMS, donc NT est en fait la troisième fois que Cutler construit un noyau à partir de zéro.

Cependant, NT ne remplace pas simplement VMS par un shell Windows. Il s’appelait à l’origine NT OS/2, un système d’exploitation mettant l’accent sur la portabilité. Il a d'abord été développé pour le processeur Intel i860, puis déplacé vers l'architecture MIPS. Microsoft a finalement changé l'orientation principale du produit NT d'OS/2 vers Win32. Un fait important est que Windows 3.1 s'est vendu à 16 millions d'exemplaires en seulement six mois.

L'une des principales choses que Kirk admirait était la conception « objet » de NT. Dans la terminologie technique propre à Microsoft, NT n'est pas un « système d'exploitation orienté objet » implémenté dans des langages tels que C++ au sens traditionnel, mais utilise une architecture « basée sur les objets ». Les ressources telles que les processus, les threads, les fichiers, les périphériques, les clés de registre, les mutex, les tâches et les jetons d'accès sont toutes gérées en tant qu'objets.

Le gestionnaire d'objets interne de NT est responsable de la création et de la destruction de ces objets, de la maintenance de l'espace de noms des objets, du suivi des objets détenus par chaque processus et de la gestion des droits d'accès correspondants. Différents composants du système utilisent ces objets via les interfaces fournies par le composant auquel l'objet appartient, de sorte que lorsque l'implémentation interne du composant sous-jacent change, cela peut éviter d'affecter les autres composants dans une certaine mesure.

L'endroit le plus simple pour les programmeurs Windows ordinaires d'entrer en contact avec cette conception est la "poignée". Lorsqu'une application ouvre un fichier, Windows ne transmet pas simplement le fichier lui-même à l'application, mais renvoie un handle et enregistre les autorisations qui ont été accordées à ce handle. Lorsque le programme fonctionnera ultérieurement sur le fichier, le système vérifiera en fonction de ces autorisations. Si un handle est copié, ses autorisations peuvent être encore réduites, mais elles ne peuvent pas être augmentées à partir de rien via l’opération de copie.

Kirk estime que cette méthode de gestion relativement unifiée pour différentes ressources système est très élégante et constitue également l'un des avantages importants de l'architecture NT.

Le modèle de sécurité de NT repose également sur les ressources, les identités et les autorisations. Une fois qu'un utilisateur se connecte à Windows, le système crée un jeton d'accès contenant l'identifiant de sécurité SID de l'utilisateur, le groupe d'utilisateurs auquel il appartient et les autorisations système associées. Les processus démarrés par les utilisateurs obtiennent généralement les jetons d'accès correspondants, et chaque objet pouvant être protégé possède un descripteur de sécurité, qui comprend une liste de contrôle d'accès qui spécifie quels SID peuvent obtenir quelles autorisations ou doivent être refusés.

Lorsqu'un processus tente d'accéder à un objet, Windows compare le jeton d'accès à la liste de contrôle d'accès de l'objet et renvoie un handle avec les autorisations appropriées. De plus, les descripteurs de sécurité peuvent contenir des listes de contrôle d'accès au système à des fins d'audit afin d'enregistrer l'accès réussi ou échoué à un objet.

Cependant, cela ne signifie pas qu'avoir un noyau bien conçu équivaut automatiquement à un système d'exploitation absolument sécurisé. Windows NT 3.5 a déjà reçu une note de sécurité C2, mais l'environnement de certification à l'époque était un ordinateur autonome sans connexion réseau, et Microsoft a également renforcé les autorisations par défaut pour les fichiers et le registre. À mesure que Windows entre dans l’ère d’Internet, les pilotes, les configurations par défaut et les exigences de compatibilité accumulés au fil des décennies auront également un impact considérable sur la sécurité du système.

L'une des principales critiques de Kirk à l'égard de Linux est que Linux utilise plusieurs mécanismes coopérants pour la sécurité et la gestion des autorisations. Les questions qu'elle a soulevées concernaient l'UID, le GID, l'ACL, les groupes de contrôle, diverses politiques de sécurité, SELinux et les autorisations du système de fichiers, etc., et elle pensait qu'il manquait un diagramme de relation d'autorisation unifié et intuitif entre ces mécanismes.

Cependant, cette complexité fait également partie de la manière dont Linux est conçu. L'UID et le GID sont utilisés pour identifier les utilisateurs et les groupes d'utilisateurs, tandis que les autorisations de fichiers et l'ACL sont responsables de la protection des fichiers. Les fonctionnalités peuvent séparer les capacités des comptes root traditionnels, par exemple permettre à un serveur Web de lier le port 80 sans obtenir les autorisations root complètes. Les espaces de noms permettent aux processus de voir les montages de systèmes de fichiers indépendants, les processus ou les environnements réseau. La technologie des conteneurs repose sur ce mécanisme. Les groupes de contrôle sont chargés de limiter l'utilisation des ressources telles que le processeur et la mémoire, et SELinux et d'autres modules de sécurité Linux peuvent imposer des politiques de sécurité supplémentaires sur cette base.

Beaucoup de ces mécanismes de Linux ont en effet été ajoutés progressivement au cours du développement du noyau. Par exemple, SELinux a été initialement proposé par la National Security Agency des États-Unis sous la forme d'un correctif indépendant en 2001. Linux a ensuite établi le cadre Linux Security Module afin que différents modèles de sécurité soient accessibles via des hooks de noyau unifiés. Aujourd'hui, le noyau Linux prend déjà en charge plusieurs mécanismes de sécurité tels que SELinux, AppArmor, Smack, TOMOYO et Landlock.

Il existe donc des différences significatives dans les philosophies de conception des deux systèmes d'exploitation. NT a tendance à centraliser la gestion autour d'un modèle objet unifié, tandis que Linux accorde davantage d'attention à la composabilité, laissant différents mécanismes prendre en charge différentes tâches et permettant aux distributions, aux administrateurs et aux scénarios d'application de se combiner.

Kirk estime que cette différence mérite particulièrement d'être revisitée aujourd'hui avec le développement rapide des agents d'intelligence artificielle. La question centrale qu'elle a soulevée était : "Qu'est-ce qu'un agent IA est autorisé à faire exactement ?"

Les programmes traditionnels s'exécutent généralement un par un selon les instructions explicitement émises par l'utilisateur, tandis que les agents IA peuvent effectuer en continu des milliers d'opérations en quelques minutes, générer et exécuter du code par eux-mêmes, lire des fichiers et concaténer plusieurs autorisations pour effectuer des tâches complexes. Par conséquent, le système d'exploitation doit non seulement déterminer « qui » ​​exécute le programme, mais doit également définir plus clairement à quelles ressources un agent d'IA peut accéder, dans quelle portée il opère et comment enregistrer ces comportements.

Kirk estime que le modèle objet de NT peut permettre au système d'exploitation d'établir des relations d'autorisation plus claires pour différentes ressources et de fournir un enregistrement d'audit plus centralisé et plus clair lorsque l'agent IA perd le contrôle. Cependant, elle a également admis qu’il s’agissait encore d’une hypothèse architecturale plutôt que d’une conclusion prouvée.

En fait, Linux a fourni de plus en plus d'outils pour résoudre ce problème. Landlock ajouté dans Linux 5.13 permet même aux processus non privilégiés de limiter activement le système de fichiers et les ressources réseau auxquels ils peuvent accéder. Ces limites peuvent être héritées des processus enfants et ne peuvent être que renforcées davantage, et non assouplies par le processus enfant. Combiné avec seccomp, Namespaces, cgroups et divers mécanismes LSM, Linux peut également isoler strictement les agents IA.

Microsoft lui-même évolue dans une direction similaire. Microsoft a annoncé Microsoft Execution Containers, ou MXC, lors de la conférence 2026 Build, permettant aux développeurs de déclarer à quelles ressources l'agent IA peut accéder, et à Windows d'appliquer ces restrictions pendant l'exécution. MXC peut également créer des comptes d'utilisateurs indépendants pour les agents, permettant au système d'attribuer chaque opération effectuée par l'agent à une identité spécifique. L'espace de travail d'agent existant de Windows 11 utilise également l'ACL pour restreindre les comptes d'agent afin que leurs autorisations ne dépassent pas celles de l'utilisateur.

En d'autres termes, Microsoft utilise désormais les mécanismes NT traditionnels tels que les SID, les jetons d'accès et les ACL pour résoudre le problème des autorisations des agents IA. C'est exactement là que Kirk estime que l'architecture NT présente des avantages. Cependant, cela ne signifie pas que Microsoft a prouvé que Linux n'est pas capable d'utiliser des agents IA. Alors que Microsoft lui-même fait progresser son système d'exploitation d'IA, il a également averti que les agents d'IA pourraient créer de nouveaux logiciels malveillants et de nouveaux risques de sécurité.

Kirk a ensuite proposé son idée historique alternative la plus intéressante : Microsoft devrait en fait lancer un "Open NT" à l'époque.

L'Open NT qu'elle envisageait ne doit pas nécessairement être complètement ouvert comme les logiciels GPL, mais permet aux grandes entreprises de modifier des composants spécifiques du noyau tout en conservant les normes de sécurité et de compatibilité de base définies par Microsoft. Par exemple, lorsqu'Amazon construisait la plate-forme de cloud computing EC2 au début, il pouvait dériver une version appelée « AmazonNT » d'Open NT et modifier lui-même le planificateur, la pile réseau ou l'allocateur de mémoire, tout en respectant les spécifications de base de compatibilité et de sécurité définies par Microsoft.

En fait, Microsoft a effectivement essayé un modèle similaire dans une certaine mesure dans le passé. Le programme Shared Source de Microsoft a permis d'accéder au code source de Windows à environ 1 600 entreprises clientes, universités et agences gouvernementales. En 2001, le ministère autrichien de l'Intérieur est devenu le premier gouvernement européen à obtenir le code source de Windows XP.

En 2006, Microsoft a également lancé Windows Research Kernel, qui permet aux chercheurs universitaires de modifier le planificateur et le gestionnaire de mémoire de NT à des fins d'enseignement et de recherche. Cependant, ces projets sont encore limités par nature au partage de code source et ne permettent pas à des entreprises telles qu'Amazon de créer et de distribuer commercialement leurs propres branches Windows NT.

Quant à la raison pour laquelle Microsoft n'a pas ouvert davantage NT, l'article estime que cela peut impliquer des revenus de licences, des droits de propriété intellectuelle, des coûts de support technique et l'engagement le plus important de Microsoft en matière de compatibilité Windows. Permettre à des tiers de modifier le noyau pendant une longue période signifiera probablement que Microsoft devra faire face à un grand nombre de problèmes de compatibilité et de sécurité entre les différentes versions.

Les développeurs Linux ont remis en question la vision d'Open NT sous un autre angle. David Airlie, impliqué depuis longtemps dans le développement du sous-système graphique du noyau Linux, estime que le véritable problème réside dans le coût à long terme de la maintenance d'une branche du noyau. Même si le code source est totalement ouvert, si les entreprises ont encore besoin de maintenir leurs propres gestionnaires ou planificateurs de mémoire modifiés 20 ans plus tard, elles doivent continuer à investir dans des équipes d'ingénierie dédiées.

Airlie a souligné qu'un grand nombre d'entreprises ont essayé de créer des versions Linux, mais après quelques années, elles trouvent souvent que le coût de maintenance de leurs propres succursales est trop élevé et choisissent finalement de soumettre les modifications à la version principale. La raison pour laquelle différentes implémentations de JVM dans l'écosystème Java peuvent exister pendant une longue période est qu'elles ont derrière elles des clients commerciaux et des sources de revenus clairs ; tandis qu'une succursale NT qui ne dessert que des entreprises internes peut avoir du mal à supporter de tels coûts à long terme.

Si Amazon modifie le planificateur de NT, les correctifs de sécurité publiés chaque mois par Microsoft devront être refusionnés, testés et vérifiés. Plus le temps passe, plus cette branche se rapproche d'une équipe de noyau de système d'exploitation qui doit être maintenue de manière indépendante. Le modèle Linux consiste à soumettre autant que possible au réseau principal un grand nombre de modifications requises par les entreprises et à les maintenir conjointement par l'ensemble de la communauté.

NT lui-même n’est pas sans bagage historique. Certains ingénieurs ont souligné que la conception cohérente du VMS n'avait pas été entièrement transférée au NT moderne. Le registre Windows est depuis longtemps l'un des composants système les plus controversés parmi les ingénieurs.

Une autre controverse naît du système graphique. Au cours de la période Windows NT 4.0, Microsoft a déplacé le gestionnaire de fenêtres, le GDI et les pilotes graphiques dans l'espace du noyau pour améliorer les performances graphiques. Cela signifie qu'un pilote graphique gravement problématique peut directement provoquer le crash de l'ensemble du système d'exploitation. Windows 2000 a ensuite ajouté un grand nombre de mécanismes tels que le modèle de pilote Windows, Plug and Play, la gestion de l'alimentation, WMI et les objets de travail.

Par conséquent, le noyau NT de Windows 11 aujourd'hui n'est plus le même que lors de la première sortie de NT 3.1 en 1993. Ce que Kirk a vraiment loué, ce sont certains des concepts architecturaux de base lors de la création de NT, plutôt que de penser que toutes les conceptions de Windows modernes sont intrinsèquement supérieures à Linux.

À en juger par les résultats historiques, Linux a finalement atteint une position dans les domaines des serveurs et du cloud computing que NT n'a pas réussi à atteindre. La licence ouverte de Linux permet à toute organisation de modifier le noyau, de l'exécuter sur divers matériels et de soumettre des améliorations au système principal. L’émergence ultérieure de conteneurs, d’outils de développement et d’immenses écosystèmes comme Android ont encore renforcé ce modèle de développement.

Ce qui est intéressant, c'est que Microsoft a travaillé dur pour que Windows exécute mieux Linux ces dernières années. Le sous-système Windows pour Linux continue de bénéficier d'améliorations en termes de performances et de réseau, et Microsoft a également lancé des fonctionnalités telles que les conteneurs WSL, permettant aux utilisateurs d'exécuter des conteneurs Linux directement dans l'environnement Windows. Google a également commencé à ajouter la prise en charge WSL à ses propres outils d'IA.

Dans le même temps, Kirk a également mentionné BSD. Elle pense que si le noyau du système d'exploitation est repensé aujourd'hui, en plus de NT, une architecture de type BSD pourrait également apparaître. Elle pense que la structure globale de BSD est relativement soignée et qu'il dispose de mécanismes d'isolement tels que les prisons à ses débuts.

Les prisons FreeBSD peuvent limiter les systèmes de fichiers, les utilisateurs et les environnements réseau qu'un processus voit, tandis que Capsicum est plus proche du modèle de capacités souligné par Kirk. Après être entré en mode Capacité, le processus ne peut pas accéder à volonté à l'espace de noms global et ne peut utiliser que les autorisations qui lui sont explicitement accordées via des descripteurs de fichiers. Il est intéressant de noter que le projet Capsicum a été achevé à l'Université de Cambridge et a reçu un financement de recherche de Google.

De ce point de vue, ce dont Kirk discute réellement n'est pas de savoir qui est le meilleur dans tous les scénarios, Windows ou Linux, mais d'une question plus fondamentale : comment le système d'exploitation doit représenter et contrôler les "autorisations".

L'idée de NT est de permettre aux ressources d'avoir des types clairs, d'attacher des autorisations d'accès aux ressources, et de les vérifier et de les enregistrer de manière uniforme par le système d'exploitation autant que possible. Linux part de la base Unix, plus flexible, et répond aux besoins de différents environnements grâce à de multiples mécanismes qui peuvent être combinés. Aucune des deux méthodes ne peut garantir à elle seule la sécurité du système.

L'émergence des agents IA rend cette question encore plus importante. Dans le passé, la question la plus importante pour les systèmes d'exploitation était de confirmer « quel utilisateur » effectuait l'opération ; à l’avenir, il devra également déterminer qui un agent d’IA peut représenter, à quelles ressources il peut accéder, combien de temps il dispose d’une autorisation, quelles opérations il peut effectuer et si le système peut prouver avec précision ce qu’il a fait.

Windows NT n'est pas devenu l'acteur dominant dans le monde des serveurs et du cloud computing, et cette position a finalement été prise par Linux. Cependant, plus de 30 ans se sont écoulés depuis l’avènement de NT 3.1. Windows utilise toujours les concepts de conception d'origine des objets, des handles, des jetons d'accès et des ACL, et Microsoft commence maintenant à utiliser ces mécanismes pour résoudre le problème d'isolation des autorisations des agents IA.

Par conséquent, l'"Open NT" imaginé par Laurie Kirk n'existe peut-être qu'à jamais dans l'histoire fictive, mais alors que les ordinateurs commencent à effectuer activement de plus en plus de tâches pour les humains, un problème de plus en plus réel se pose à tous les systèmes d'exploitation : lorsque les logiciels commencent à agir au nom des humains, jusqu'où devrions-nous leur permettre d'aller ?