Google-Forscher sagen, dass das Windows NT-Kernel-Design Linux immer noch in den Schatten stellt

Zusammenfassung:

Laurie Kirk, eine Forscherin, die vier Jahre lang als Reverse Engineer bei Microsoft gearbeitet hat und jetzt bei Google arbeitet, hat kürzlich die jahrzehntelange Debatte zwischen Windows und Linux neu entfacht. Sie erklärte öffentlich, dass der Windows NT-Kernel aus Sicht des technischen Designs immer noch ein „technisches Wunder“ sei und Linux in vielen Aspekten sogar in den Schatten stellt.

Kirk betonte, dass sie nicht das Startmenü, Copilot oder die Werbung von Windows 11 bewundere, sondern die zugrunde liegende NT-Kernel-Architektur von Windows. Sie glaubt, dass NT von Anfang an ein relativ vollständiges Objektmodell und Sicherheitssystem etabliert hat, während Linux nach und nach Sicherheitsmechanismen wie Funktionen, Namespaces und SELinux auf der Basis des traditionellen Unix hinzugefügt hat, sodass es insgesamt verteilter zu sein scheint.

Kirk sagte auf sozialen Plattformen, dass NT, wenn man es aus der Perspektive eines Programmierers am einfachsten beschreibt, eher einem „objektorientierten“ Design ähnelt und von Anfang an über ein sehr starkes Sicherheitsmodell verfügt; Im Gegensatz dazu wurden viele der Sicherheitsfunktionen von Linux erst später hinzugefügt. Sie glaubt, dass, wenn heute ein zukunftsorientierter Betriebssystemkernel von Grund auf entworfen wird, die endgültige Form wahrscheinlich nicht wie Linux aussehen wird, sondern eher NT ähneln und möglicherweise sogar einem BSD-Zweig ähneln wird.

Windows NT ist eigentlich die technische Grundlage für alle wichtigen Windows-Versionen seit 1993, einschließlich des heutigen Windows 11. Microsoft stellte 1988 Dave Cutler ein, der zuvor bei DEC für die VMS-Betriebssystementwicklung verantwortlich war. Laut Microsoft verbrachte ein kleines Team ehemaliger DEC-Ingenieure unter der Leitung von Cutler etwa sechs Monate mit der Entwicklung der Spezifikation, bevor es tatsächlich mit dem Schreiben von Code begann. Zu den anfänglichen Zielen gehörten Portabilität, Multiprozessorunterstützung und eine Sicherheitszertifizierung der Stufe C2.

Der pensionierte Microsoft-Ingenieur Dave Plummer nahm ebenfalls an der Diskussion teil. Er wies darauf hin, dass NT nicht das erste Mal sei, dass Cutler einen Betriebssystemkern von Grund auf neu entwickelt habe. Er hat zuvor an RSX-11M und VMS teilgenommen, sodass NT tatsächlich das dritte Mal ist, dass Cutler einen Kernel von Grund auf erstellt hat.

NT ersetzt VMS jedoch nicht einfach durch eine Windows-Shell. Ursprünglich hieß es NT OS/2, ein Betriebssystem, bei dem die Portabilität im Vordergrund stand. Es wurde zunächst für den Intel i860-Prozessor entwickelt und dann auf die MIPS-Architektur umgestellt. Microsoft änderte schließlich die Hauptproduktausrichtung von NT von OS/2 auf Win32. Ein wichtiger Hintergrund war, dass Windows 3.1 in nur sechs Monaten 16 Millionen Mal verkauft wurde.

Eines der wichtigsten Dinge, die Kirk bewunderte, war das „Objekt“-Design von NT. In der technischen Terminologie von Microsoft ist NT kein „objektorientiertes Betriebssystem“, das im herkömmlichen Sinne in Sprachen wie C++ implementiert ist, sondern eine „objektbasierte“ Architektur verwendet. Ressourcen wie Prozesse, Threads, Dateien, Geräte, Registrierungsschlüssel, Mutexe, Jobs und Zugriffstoken werden alle als Objekte verwaltet.

Der interne Objektmanager von NT ist dafür verantwortlich, diese Objekte zu erstellen und zu zerstören, den Objekt-Namespace zu pflegen, zu verfolgen, welche Objekte jeder Prozess enthält, und die entsprechenden Zugriffsrechte zu verwalten. Verschiedene Systemkomponenten verwenden diese Objekte über die Schnittstellen, die von der Komponente bereitgestellt werden, zu der das Objekt gehört. Wenn sich also die interne Implementierung der zugrunde liegenden Komponente ändert, kann dies bis zu einem gewissen Grad Auswirkungen auf andere Komponenten vermeiden.

Der einfachste Ort für normale Windows-Programmierer, mit diesem Design in Berührung zu kommen, ist der „Griff“. Wenn eine Anwendung eine Datei öffnet, übergibt Windows nicht einfach die Datei selbst an die Anwendung, sondern gibt ein Handle zurück und zeichnet die Berechtigungen auf, die dem Handle erteilt wurden. Wenn das Programm die Datei später bearbeitet, führt das System eine Überprüfung anhand dieser Berechtigungen durch. Wenn ein Handle kopiert wird, können seine Berechtigungen weiter reduziert werden, sie können jedoch nicht aus dem Nichts durch den Kopiervorgang erhöht werden.

Kirk glaubt, dass diese relativ einheitliche Verwaltungsmethode für verschiedene Systemressourcen sehr elegant ist und auch einen der wichtigen Vorteile der NT-Architektur darstellt.

Das Sicherheitsmodell von NT basiert ebenfalls auf Ressourcen, Identitäten und Berechtigungen. Nachdem sich ein Benutzer bei Windows angemeldet hat, erstellt das System ein Zugriffstoken, das die Sicherheits-ID SID des Benutzers, die Benutzergruppe, zu der er gehört, und zugehörige Systemberechtigungen enthält. Von Benutzern gestartete Prozesse erhalten in der Regel entsprechende Zugriffstoken, und jedes Objekt, das geschützt werden kann, verfügt über eine Sicherheitsbeschreibung, die eine Zugriffskontrollliste enthält, die angibt, welche SIDs welche Berechtigungen erhalten können oder verweigert werden müssen.

Wenn ein Prozess versucht, auf ein Objekt zuzugreifen, gleicht Windows das Zugriffstoken mit der Zugriffskontrollliste des Objekts ab und gibt ein Handle mit den entsprechenden Berechtigungen zurück. Darüber hinaus können Sicherheitsbeschreibungen Systemzugriffskontrolllisten zu Prüfzwecken enthalten, um den erfolgreichen oder fehlgeschlagenen Zugriff auf ein Objekt aufzuzeichnen.

Dies bedeutet jedoch nicht, dass ein gut gestalteter Kernel automatisch ein absolut sicheres Betriebssystem bedeutet. Windows NT 3.5 erhielt einst die Sicherheitsbewertung C2, die damalige Zertifizierungsumgebung war jedoch ein eigenständiger Computer ohne Netzwerkverbindung, und Microsoft hat außerdem die Standardberechtigungen für Dateien und Registrierung gestärkt. Mit dem Eintritt von Windows in das Internetzeitalter werden auch über Jahrzehnte angesammelte Treiber, Standardkonfigurationen und Kompatibilitätsanforderungen einen großen Einfluss auf die Systemsicherheit haben.

Einer von Kirks Hauptkritikpunkten an Linux ist, dass Linux mehrere kooperierende Mechanismen für Sicherheit und Berechtigungsverwaltung verwendet. Die von ihr aufgeworfenen Fragen umfassten UID, GID, ACL, cgroups, verschiedene Sicherheitsrichtlinien, SELinux und Dateisystemberechtigungen usw. und glaubte, dass es an einem einheitlichen und intuitiven Berechtigungsbeziehungsdiagramm zwischen diesen Mechanismen mangelte.

Diese Komplexität ist jedoch auch Teil der Art und Weise, wie Linux konzipiert ist. UID und GID werden zur Identifizierung von Benutzern und Benutzergruppen verwendet, während Dateiberechtigungen und ACL für den Schutz von Dateien verantwortlich sind. Funktionen können die Funktionen herkömmlicher Root-Konten trennen, z. B. die Möglichkeit, dass ein Webserver Port 80 bindet, ohne vollständige Root-Berechtigungen zu erhalten. Namespaces ermöglichen es Prozessen, unabhängige Dateisystem-Mounts, Prozesse oder Netzwerkumgebungen zu sehen. Die Containertechnologie basiert auf diesem Mechanismus. cgroups sind dafür verantwortlich, die Nutzung von Ressourcen wie CPU und Speicher zu begrenzen, und SELinux und andere Linux-Sicherheitsmodule können auf dieser Grundlage zusätzliche Sicherheitsrichtlinien durchsetzen.

Viele dieser Mechanismen von Linux wurden tatsächlich nach und nach während der Entwicklung des Kernels hinzugefügt. Beispielsweise wurde SELinux ursprünglich von der US-amerikanischen National Security Agency in Form eines unabhängigen Patches im Jahr 2001 vorgeschlagen. Linux etablierte daraufhin das Linux Security Module-Framework, sodass über einheitliche Kernel-Hooks auf verschiedene Sicherheitsmodelle zugegriffen werden kann. Der Linux-Kernel unterstützt bereits heute mehrere Sicherheitsmechanismen wie SELinux, AppArmor, Smack, TOMOYO und Landlock.

Daher gibt es tatsächlich erhebliche Unterschiede in den Designphilosophien der beiden Betriebssysteme. NT neigt dazu, die Verwaltung um ein einheitliches Objektmodell herum zu zentralisieren, während Linux mehr Wert auf die Zusammensetzbarkeit legt, indem es verschiedene Mechanismen unterschiedliche Aufgaben übernehmen lässt und es Distributionen, Administratoren und Anwendungsszenarien ermöglicht, sich selbst zu kombinieren.

Kirk ist davon überzeugt, dass dieser Unterschied angesichts der rasanten Entwicklung von Agenten für künstliche Intelligenz besonders heute eine erneute Betrachtung wert ist. Die Kernfrage, die sie stellte, war: „Was genau darf ein KI-Agent tun?“

Herkömmliche Programme führen in der Regel eines nach dem anderen gemäß den vom Benutzer explizit erteilten Anweisungen aus, während KI-Agenten kontinuierlich Tausende von Vorgängen in wenigen Minuten ausführen, selbst Code generieren und ausführen, Dateien lesen und mehrere Berechtigungen verknüpfen können, um komplexe Aufgaben auszuführen. Daher muss das Betriebssystem nicht nur bestimmen, „wer“ das Programm ausführt, sondern auch klarer definieren, auf welche Ressourcen ein KI-Agent zugreifen kann, in welchem ​​Umfang er agiert und wie dieses Verhalten aufgezeichnet wird.

Kirk glaubt, dass das Objektmodell von NT es dem Betriebssystem ermöglichen kann, klarere Berechtigungsbeziehungen für verschiedene Ressourcen einzurichten und eine zentralere und klarere Prüfaufzeichnung bereitzustellen, wenn der KI-Agent die Kontrolle verliert. Allerdings räumte sie auch ein, dass dies immer noch eine architektonische Hypothese und keine bewiesene Schlussfolgerung sei.

Tatsächlich stellt Linux immer mehr Tools für dieses Problem bereit. Mit Landlock, das in Linux 5.13 hinzugefügt wurde, können selbst unprivilegierte Prozesse das Dateisystem und die Netzwerkressourcen, auf die sie zugreifen können, aktiv einschränken. Diese Grenzen können an untergeordnete Prozesse vererbt werden und können durch den untergeordneten Prozess nur weiter verschärft, nicht gelockert werden. In Kombination mit seccomp, Namespaces, cgroups und verschiedenen LSM-Mechanismen kann Linux auch KI-Agenten strikt isolieren.

Microsoft selbst bewegt sich in eine ähnliche Richtung. Microsoft kündigte auf der Build-Konferenz 2026 Microsoft Execution Containers (MXC) an, die es Entwicklern ermöglichen, zu deklarieren, auf welche Ressourcen der KI-Agent zugreifen kann, und Windows diese Einschränkungen während der Laufzeit durchzusetzen. MXC kann auch unabhängige Benutzerkonten für Agenten erstellen, sodass das System jede vom Agenten ausgeführte Operation einer bestimmten Identität zuordnen kann. Auch der bestehende Agent Workspace von Windows 11 verwendet ACL, um Agentenkonten einzuschränken, sodass ihre Berechtigungen nicht über die des Benutzers hinausgehen.

Mit anderen Worten: Microsoft verwendet jetzt traditionelle NT-Mechanismen wie SIDs, Zugriffstoken und ACLs, um das Problem der KI-Agentenberechtigungen zu lösen. Genau hier sieht Kirk die Vorteile der NT-Architektur. Dies bedeutet jedoch nicht, dass Microsoft bewiesen hat, dass Linux nicht zu KI-Agenten fähig ist. Während Microsoft selbst sein KI-Betriebssystem weiterentwickelt, hat es auch davor gewarnt, dass KI-Agenten neue Malware und Sicherheitsrisiken schaffen könnten.

Kirk schlug dann seine interessanteste alternative historische Idee vor: Microsoft sollte damals tatsächlich ein „Open NT“ auf den Markt bringen.

Das von ihr vorgestellte Open NT muss nicht unbedingt vollständig offen sein wie GPL-Software, sondern ermöglicht es großen Unternehmen, bestimmte Komponenten im Kernel zu ändern und gleichzeitig die von Microsoft festgelegten grundlegenden Sicherheits- und Kompatibilitätsstandards beizubehalten. Als Amazon beispielsweise in den Anfängen die EC2-Cloud-Computing-Plattform baute, konnte es eine Version namens „AmazonNT“ von Open NT ableiten und den Scheduler, den Netzwerkstapel oder die Speicherzuweisung selbständig modifizieren, während es dennoch den von Microsoft definierten Kernkompatibilitäts- und Sicherheitsspezifikationen entsprach.

Tatsächlich hat Microsoft in der Vergangenheit in gewissem Umfang tatsächlich ein ähnliches Modell ausprobiert. Das Shared Source-Programm von Microsoft hat rund 1.600 Unternehmenskunden, Universitäten und Regierungsbehörden Zugriff auf den Windows-Quellcode ermöglicht. Im Jahr 2001 erhielt das österreichische Innenministerium als erste europäische Regierung den Windows XP-Quellcode.

Im Jahr 2006 brachte Microsoft außerdem den Windows Research Kernel auf den Markt, der es Universitätsforschern ermöglicht, den Scheduler und Speichermanager von NT für Lehre und Forschung zu modifizieren. Bei diesen Projekten handelt es sich jedoch immer noch um eine eingeschränkte Quellcode-Freigabe, sodass Unternehmen wie Amazon keine eigenen Windows NT-Zweige erstellen und kommerziell vertreiben können.

Was den Grund angeht, warum Microsoft NT nicht weiter geöffnet hat, geht der Artikel davon aus, dass es sich möglicherweise um Lizenzeinnahmen, geistige Eigentumsrechte, Kosten für technischen Support und Microsofts wichtigstes Engagement für die Windows-Kompatibilität handelt. Wenn man Dritten über einen längeren Zeitraum erlaubt, den Kernel zu modifizieren, bedeutet dies wahrscheinlich, dass Microsoft mit einer Vielzahl von Kompatibilitäts- und Sicherheitsproblemen zwischen verschiedenen Versionen konfrontiert wird.

Linux-Entwickler haben die Open NT-Vision aus einem anderen Blickwinkel in Frage gestellt. David Airlie, der seit langem an der Entwicklung des Linux-Kernel-Grafiksubsystems beteiligt ist, glaubt, dass das eigentliche Problem in den langfristigen Kosten für die Wartung eines Kernel-Zweigs liegt. Selbst wenn der Quellcode vollständig offen ist, müssen Unternehmen weiterhin in dedizierte Entwicklungsteams investieren, wenn sie 20 Jahre später immer noch ihre eigenen modifizierten Speichermanager oder -planer verwalten müssen.

Airlie wies darauf hin, dass viele Unternehmen versucht haben, Linux-Versionen abzuspalten, aber nach ein paar Jahren stellten sie oft fest, dass die Kosten für die Wartung ihrer eigenen Niederlassungen zu hoch waren, und entschieden sich schließlich dafür, Änderungen an die Hauptlinie zurückzusenden. Der Grund, warum unterschiedliche JVM-Implementierungen im Java-Ökosystem über einen langen Zeitraum existieren können, liegt darin, dass sie klare kommerzielle Kunden und Einnahmequellen hinter sich haben; Für eine NT-Zweigstelle, die nur interne Unternehmen bedient, dürfte es jedoch auf lange Sicht schwierig sein, solche Kosten zu tragen.

Wenn Amazon den NT-Planer ändert, müssen die Sicherheitsupdates, die Microsoft jeden Monat veröffentlicht, erneut zusammengeführt, getestet und verifiziert werden. Je länger die Zeit vergeht, desto näher rückt dieser Zweig an ein Betriebssystem-Kernel-Team heran, das unabhängig gewartet werden muss. Das Linux-Modell besteht darin, eine große Anzahl von Änderungen, die von Unternehmen benötigt werden, so weit wie möglich an die Hauptlinie zurückzusenden und von der gesamten Community gemeinsam zu pflegen.

NT selbst ist nicht ohne historischen Ballast. Einige Ingenieure wiesen darauf hin, dass das einheitliche Design von VMS nicht vollständig auf modernes NT übertragen wurde. Die Windows-Registrierung ist unter Ingenieuren seit langem eine der umstrittensten Systemkomponenten.

Eine weitere Kontroverse ergibt sich aus dem Grafiksystem. Während der Windows NT 4.0-Ära hat Microsoft Window Manager, GDI und Grafiktreiber in den Kernelbereich verschoben, um die Grafikleistung zu verbessern. Das bedeutet, dass ein stark problematischer Grafiktreiber direkt zum Absturz des gesamten Betriebssystems führen kann. Windows 2000 fügte dann eine Vielzahl von Mechanismen hinzu, wie z. B. Windows-Treibermodell, Plug-and-Play, Energieverwaltung, WMI und Jobobjekte.

Daher ist der NT-Kernel in Windows 11 heute nicht mehr derselbe Kernel wie bei der ersten Veröffentlichung von NT 3.1 im Jahr 1993. Was Kirk bei der Gründung von NT wirklich lobte, waren einige der grundlegenden Architekturkonzepte, anstatt zu glauben, dass alle Designs moderner Windows von Natur aus Linux überlegen seien.

Nach historischen Ergebnissen zu urteilen, erreichte Linux schließlich eine Position in den Bereichen Server und Cloud Computing, die NT nicht erreichen konnte. Die offene Lizenz von Linux ermöglicht es jeder Organisation, den Kernel zu ändern, ihn auf einer Vielzahl von Hardware auszuführen und Verbesserungen an die Hauptlinie zurückzusenden. Das spätere Aufkommen von Containern, Entwicklungstools und riesigen Ökosystemen wie Android hat dieses Entwicklungsmodell weiter gestärkt.

Interessant ist, dass Microsoft in den letzten Jahren hart daran gearbeitet hat, Windows besser auf Linux laufen zu lassen. Das Windows-Subsystem für Linux erhält weiterhin Leistungs- und Netzwerkverbesserungen, und Microsoft hat außerdem Funktionen wie WSL-Container eingeführt, die es Benutzern ermöglichen, Linux-Container direkt in der Windows-Umgebung auszuführen. Google hat außerdem damit begonnen, WSL-Unterstützung zu seinen eigenen KI-Tools hinzuzufügen.

Gleichzeitig erwähnte Kirk auch BSD. Sie glaubt, dass bei einer Neugestaltung des Betriebssystemkerns heute neben NT auch eine BSD-ähnliche Architektur entstehen könnte. Sie glaubt, dass die Gesamtstruktur von BSD relativ ordentlich ist und dass es in seinen Anfängen über Isolationsmechanismen wie Jails verfügte.

FreeBSD-Jails können die Dateisysteme, Benutzer und Netzwerkumgebungen einschränken, die ein Prozess sieht, während Capsicum dem von Kirk hervorgehobenen Funktionsmodell näher kommt. Nach dem Eintritt in den Capability-Modus kann der Prozess nicht nach Belieben auf den globalen Namespace zugreifen und kann nur Berechtigungen verwenden, die ihm explizit über Dateideskriptoren gewährt wurden. Interessanterweise wurde das Capsicum-Projekt an der Universität Cambridge abgeschlossen und erhielt Forschungsgelder von Google.

Aus dieser Perspektive geht es Kirk eigentlich nicht darum, wer in allen Szenarien besser ist, Windows oder Linux, sondern um eine grundlegendere Frage: Wie das Betriebssystem „Berechtigungen“ darstellen und steuern soll.

Die Idee von NT besteht darin, Ressourcen klare Typen zu geben, Zugriffsberechtigungen an Ressourcen anzuhängen und sie vom Betriebssystem so weit wie möglich einheitlich zu überprüfen und aufzuzeichnen. Linux basiert auf der flexibleren Unix-Grundlage und erfüllt die Anforderungen verschiedener Umgebungen durch mehrere kombinierbare Mechanismen. Keine der beiden Methoden allein kann die Systemsicherheit gewährleisten.

Das Aufkommen von KI-Agenten macht dieses Thema noch wichtiger. In der Vergangenheit bestand die wichtigste Frage für Betriebssysteme darin, zu bestätigen, „welcher Benutzer“ den Vorgang ausführt. Künftig muss darüber hinaus beantwortet werden, wen ein KI-Agent repräsentieren kann, auf welche Ressourcen er zugreifen kann, wie lange er die Berechtigung hat, welche Operationen er ausführen kann und ob das System genau nachweisen kann, was er getan hat.

Windows NT wurde nicht zum dominierenden Akteur in der Server- und Cloud-Computing-Welt, und diese Position wurde letztendlich von Linux eingenommen. Allerdings sind seit der Einführung von NT 3.1 mehr als 30 Jahre vergangen. Windows verwendet immer noch die ursprünglichen Designkonzepte von Objekten, Handles, Zugriffstokens und ACLs, und Microsoft beginnt nun, diese Mechanismen zu nutzen, um das Berechtigungsisolationsproblem von KI-Agenten zu lösen.

Daher existiert das von Laurie Kirk ins Auge gefasste „Open NT“ möglicherweise nur für immer in der fiktiven Geschichte, aber da Computer beginnen, aktiv immer mehr Aufgaben für Menschen auszuführen, stehen alle Betriebssysteme vor einem immer realeren Problem: Wenn Software beginnt, im Namen von Menschen zu handeln, wie weit sollten wir es dann zulassen, dass sie geht?