Un ricercatore di Google afferma che il design del kernel di Windows NT fa ancora impallidire Linux

Riassunto:

Laurie Kirk, una ricercatrice che ha lavorato come reverse engineer presso Microsoft per quattro anni e ora lavora presso Google, ha recentemente riacceso il dibattito decennale tra Windows e Linux. Ha dichiarato pubblicamente che il kernel di Windows NT è ancora un "miracolo ingegneristico" dal punto di vista della progettazione ingegneristica, e sotto molti aspetti fa impallidire Linux.

Kirk ha sottolineato che ciò che ammirava non era il menu Start, Copilot o le pubblicità di Windows 11, ma l'architettura del kernel NT alla base di Windows. Secondo lei, NT ha creato fin dall'inizio un modello a oggetti e un sistema di sicurezza relativamente completo, mentre Linux ha gradualmente aggiunto meccanismi di sicurezza come Capabilities, Namespace e SELinux sulla base di Unix tradizionale, quindi nel complesso appare più dispersivo.

Kirk ha affermato sulle piattaforme social che, se si fornisce la descrizione più semplice dal punto di vista di un programmatore, NT è più vicino a un design "orientato agli oggetti" e ha un modello di sicurezza molto forte fin dall'inizio; al contrario, molte delle funzionalità di sicurezza di Linux furono gradualmente aggiunte in seguito. Lei ritiene che se un kernel del sistema operativo orientato al futuro fosse progettato da zero oggi, la forma finale probabilmente non assomiglierebbe a Linux, ma sarebbe più vicina a NT e potrebbe anche essere simile a qualche ramo BSD.

Windows NT è in realtà la base tecnica di tutte le principali versioni di Windows dal 1993, compreso l'attuale Windows 11. Microsoft ha assunto Dave Cutler nel 1988, che in precedenza era stato responsabile dello sviluppo del sistema operativo VMS presso DEC. Secondo Microsoft, un piccolo team di ex ingegneri DEC guidati da Cutler ha trascorso circa sei mesi a sviluppare le specifiche prima di iniziare effettivamente a scrivere il codice. Gli obiettivi iniziali includevano portabilità, supporto multiprocessore e certificazione di sicurezza di livello C2.

Al dibattito ha partecipato anche l'ingegnere Microsoft in pensione Dave Plummer. Ha sottolineato che NT non è la prima volta che Cutler progetta un kernel del sistema operativo da zero. Ha già partecipato a RSX-11M e VMS, quindi NT è in realtà la terza volta che Cutler costruisce un kernel da zero.

Tuttavia, NT non sostituisce semplicemente VMS con una shell Windows. Originariamente si chiamava NT OS/2, un sistema operativo che enfatizzava la portabilità. È stato inizialmente sviluppato per il processore Intel i860 e poi spostato sull'architettura MIPS. Alla fine Microsoft cambiò la direzione del prodotto principale di NT da OS/2 a Win32. Un fatto importante è che Windows 3.1 ha venduto 16 milioni di copie in soli sei mesi.

Una delle cose principali che Kirk ammirava era il design degli "oggetti" di NT. Nella terminologia tecnica di Microsoft, NT non è un "sistema operativo orientato agli oggetti" implementato in linguaggi come C++ nel senso tradizionale, ma utilizza un'architettura "basata sugli oggetti". Risorse come processi, thread, file, dispositivi, chiavi di registro, mutex, lavori e token di accesso sono tutte gestite come oggetti.

Il gestore degli oggetti interni di NT è responsabile della creazione e della distruzione di questi oggetti, del mantenimento dello spazio dei nomi degli oggetti, del monitoraggio degli oggetti conservati da ciascun processo e della gestione dei diritti di accesso corrispondenti. Diversi componenti del sistema utilizzano questi oggetti attraverso le interfacce fornite dal componente a cui appartiene l'oggetto, quindi quando l'implementazione interna del componente sottostante cambia, può evitare di influenzare in una certa misura altri componenti.

Il posto più semplice per i normali programmatori Windows con cui entrare in contatto con questo design è l'"handle". Quando un'applicazione apre un file, Windows non consegna semplicemente il file stesso all'applicazione, ma restituisce un handle e registra le autorizzazioni concesse all'handle. Quando il programma opererà sul file in un secondo momento, il sistema controllerà in base a queste autorizzazioni. Se un handle viene copiato, i suoi permessi possono essere ulteriormente ridotti, ma non possono essere aumentati dal nulla tramite l'operazione di copia.

Kirk ritiene che questo metodo di gestione relativamente unificato per diverse risorse di sistema sia molto elegante e sia anche uno degli importanti vantaggi dell'architettura NT.

Il modello di sicurezza di NT si basa anche su risorse, identità e autorizzazioni. Dopo che un utente ha effettuato l'accesso a Windows, il sistema crea un token di accesso che contiene il SID dell'identificatore di sicurezza dell'utente, il gruppo di utenti a cui appartiene e le relative autorizzazioni di sistema. I processi avviati dagli utenti solitamente ottengono i token di accesso corrispondenti e ogni oggetto che può essere protetto ha un descrittore di sicurezza, che include un elenco di controllo degli accessi che specifica quali SID possono ottenere quali autorizzazioni o devono essere negati.

Quando un processo tenta di accedere a un oggetto, Windows confronta il token di accesso con l'elenco di controllo degli accessi dell'oggetto e restituisce un handle con le autorizzazioni appropriate. Inoltre, i descrittori di sicurezza possono contenere elenchi di controllo di accesso al sistema a scopo di controllo per registrare gli accessi riusciti o non riusciti a un oggetto.

Tuttavia, ciò non significa che avere un kernel ben progettato equivalga automaticamente a un sistema operativo assolutamente sicuro. Windows NT 3.5 una volta riceveva una valutazione di sicurezza C2, ma l'ambiente di certificazione a quel tempo era un computer autonomo senza connessione di rete e Microsoft ha anche rafforzato le autorizzazioni predefinite per file e registro. Con l'ingresso di Windows nell'era di Internet, anche i driver, le configurazioni predefinite e i requisiti di compatibilità accumulati nel corso di decenni avranno un enorme impatto sulla sicurezza del sistema.

Una delle principali critiche mosse da Kirk a Linux è che Linux utilizza molteplici meccanismi cooperanti per la sicurezza e la gestione dei permessi. Le domande che ha sollevato includevano UID, GID, ACL, cgroups, varie policy di sicurezza, SELinux e permessi del file system, ecc., e riteneva che mancasse un diagramma unificato e intuitivo delle relazioni dei permessi tra questi meccanismi.

Tuttavia, questa complessità fa parte anche del modo in cui è progettato Linux. UID e GID vengono utilizzati per identificare utenti e gruppi di utenti, mentre le autorizzazioni dei file e l'ACL sono responsabili della protezione dei file. Le funzionalità possono separare le funzionalità degli account root tradizionali, ad esempio consentire a un server Web di associare la porta 80 senza ottenere autorizzazioni root complete. Gli spazi dei nomi consentono ai processi di vedere montaggi di file system, processi o ambienti di rete indipendenti. La tecnologia dei container si basa su questo meccanismo. I cgroup sono responsabili di limitare l'uso di risorse come CPU e memoria, e SELinux e altri moduli di sicurezza Linux possono imporre politiche di sicurezza aggiuntive su questa base.

Molti di questi meccanismi di Linux sono stati infatti aggiunti gradualmente durante lo sviluppo del kernel. SELinux, ad esempio, è stato originariamente proposto dalla National Security Agency statunitense sotto forma di patch indipendente nel 2001. Successivamente Linux ha creato il framework Linux Security Module in modo che sia possibile accedere a diversi modelli di sicurezza tramite kernel hook unificati. Oggi, il kernel Linux supporta già più meccanismi di sicurezza come SELinux, AppArmor, Smack, TOMOYO e Landlock.

Pertanto, esistono differenze significative nelle filosofie di progettazione dei due sistemi operativi. NT tende a centralizzare la gestione attorno a un modello a oggetti unificato, mentre Linux presta maggiore attenzione alla componibilità, lasciando che meccanismi diversi assumano compiti diversi e consentendo a distribuzioni, amministratori e scenari applicativi di combinarsi.

Kirk ritiene che questa differenza valga la pena di essere rivisitata soprattutto oggi, con il rapido sviluppo degli agenti di intelligenza artificiale. La domanda principale che ha sollevato è stata: "Cosa può fare esattamente un agente AI?"

I programmi tradizionali di solito vengono eseguiti uno per uno secondo le istruzioni esplicitamente impartite dall'utente, mentre gli agenti di intelligenza artificiale possono eseguire continuamente migliaia di operazioni in pochi minuti, generare ed eseguire codice da soli, leggere file e concatenare più autorizzazioni per completare attività complesse. Pertanto, il sistema operativo non deve solo determinare “chi” sta eseguendo il programma, ma deve anche definire più chiaramente a quali risorse può accedere un agente AI, in quale ambito opera e come registrare questi comportamenti.

Kirk ritiene che il modello a oggetti di NT possa consentire al sistema operativo di stabilire relazioni di autorizzazione più chiare per diverse risorse e fornire un record di audit più centralizzato e chiaro quando l'agente AI perde il controllo. Tuttavia, ha anche ammesso che si tratta ancora di un’ipotesi architettonica e non di una conclusione comprovata.

In effetti, Linux ha fornito sempre più strumenti per risolvere questo problema. Landlock aggiunto in Linux 5.13 consente anche ai processi non privilegiati di limitare attivamente il file system e le risorse di rete a cui possono accedere. Questi limiti possono essere ereditati dai processi figli e possono solo essere ulteriormente rafforzati, non allentati dal processo figlio. In combinazione con seccomp, namespace, cgroup e vari meccanismi LSM, Linux può anche isolare rigorosamente gli agenti AI.

La stessa Microsoft si sta muovendo in una direzione simile. Microsoft ha annunciato Microsoft Execution Containers, o MXC, alla conferenza Build 2026, consentendo agli sviluppatori di dichiarare a quali risorse può accedere l'agente AI e a Windows di applicare queste restrizioni durante il runtime. MXC può anche creare account utente indipendenti per gli agenti, consentendo al sistema di attribuire ogni operazione eseguita dall'agente a un'identità specifica. Anche l'area di lavoro agente esistente di Windows 11 utilizza l'ACL per limitare gli account agente in modo che le relative autorizzazioni non superino quelle dell'utente.

In altre parole, Microsoft sta ora utilizzando i tradizionali meccanismi NT come SID, token di accesso e ACL per risolvere il problema delle autorizzazioni degli agenti AI. Questo è esattamente il punto in cui Kirk ritiene che l'architettura NT presenti dei vantaggi. Tuttavia, ciò non significa che Microsoft abbia dimostrato che Linux non sia in grado di utilizzare agenti IA. Mentre la stessa Microsoft sta facendo avanzare il suo sistema operativo AI, ha anche avvertito che gli agenti AI potrebbero creare nuovi malware e rischi per la sicurezza.

Kirk propose quindi la sua idea storica alternativa più interessante: allora Microsoft avrebbe dovuto lanciare effettivamente un "Open NT".

L'Open NT da lei immaginato non deve necessariamente essere completamente aperto come il software GPL, ma consente alle grandi aziende di modificare componenti specifici nel kernel mantenendo gli standard di sicurezza e compatibilità di base stabiliti da Microsoft. Ad esempio, quando Amazon stava costruendo la piattaforma di cloud computing EC2 nei primi tempi, poteva derivare una versione chiamata "AmazonNT" da Open NT e modificare da sola lo scheduler, lo stack di rete o l'allocatore di memoria, rispettando comunque le specifiche fondamentali di compatibilità e sicurezza definite da Microsoft.

In effetti, Microsoft ha già provato in una certa misura un modello simile in passato. Il programma Shared Source di Microsoft ha fornito l'accesso al codice sorgente di Windows a circa 1.600 clienti aziendali, università ed enti governativi. Nel 2001, il Ministero degli Interni austriaco è stato il primo governo europeo a ottenere il codice sorgente di Windows XP.

Nel 2006, Microsoft ha lanciato anche il Windows Research Kernel, che consente ai ricercatori universitari di modificare lo scheduler e il gestore della memoria di NT per l'insegnamento e la ricerca. Tuttavia, questi progetti sono ancora di natura limitata per la condivisione del codice sorgente e non consentono ad aziende come Amazon di creare e distribuire commercialmente i propri rami Windows NT.

Per quanto riguarda il motivo per cui Microsoft non ha ulteriormente aperto NT, l'articolo ritiene che ciò possa coinvolgere i proventi delle licenze, i diritti di proprietà intellettuale, i costi del supporto tecnico e l'impegno più importante di Microsoft nei confronti della compatibilità con Windows. Consentire a terzi di modificare il kernel per un lungo periodo significa probabilmente che Microsoft dovrà affrontare un gran numero di problemi di compatibilità e sicurezza tra le diverse versioni.

Gli sviluppatori Linux hanno messo in discussione la visione di Open NT da un'altra angolazione. David Airlie, che è stato a lungo coinvolto nello sviluppo del sottosistema grafico del kernel Linux, ritiene che il vero problema sia il costo a lungo termine del mantenimento di un ramo del kernel. Anche se il codice sorgente è completamente aperto, se 20 anni dopo le aziende hanno ancora bisogno di mantenere i propri gestori di memoria o scheduler modificati, devono continuare a investire in team di ingegneri dedicati.

Airlie ha sottolineato che un gran numero di aziende hanno provato a creare un fork delle versioni Linux, ma dopo alcuni anni spesso scoprono che il costo di mantenimento delle proprie filiali è troppo alto e alla fine scelgono di inviare nuovamente le modifiche alla linea principale. Il motivo per cui diverse implementazioni JVM nell'ecosistema Java possono esistere per molto tempo è perché hanno alle spalle chiari clienti commerciali e fonti di reddito; mentre una filiale NT che serve solo imprese interne potrebbe avere difficoltà a sostenere tali costi a lungo termine.

Se Amazon modifica lo scheduler di NT, le correzioni di sicurezza che Microsoft rilascia ogni mese dovranno essere riunite, testate e verificate. Più passa il tempo, più questo ramo si avvicina a un team del kernel del sistema operativo che deve essere mantenuto in modo indipendente. Il modello Linux prevede di sottoporre il maggior numero possibile di modifiche richieste dalle aziende alla linea principale e di essere mantenute congiuntamente dall'intera comunità.

Il NT stesso non è privo di bagaglio storico. Alcuni ingegneri hanno sottolineato che il design coerente del VMS non è stato completamente trasferito al moderno NT. Il registro di Windows è da tempo uno dei componenti di sistema più controversi tra gli ingegneri.

Un'altra controversia nasce dal sistema grafico. Durante il periodo di Windows NT 4.0, Microsoft ha spostato Window Manager, GDI e driver grafici nello spazio del kernel per migliorare le prestazioni grafiche. Ciò significa che un driver grafico gravemente problematico può causare direttamente il crash dell'intero sistema operativo. Windows 2000 ha poi aggiunto un gran numero di meccanismi come il modello di driver di Windows, Plug and Play, gestione dell'alimentazione, WMI e oggetti lavoro.

Pertanto, il kernel NT in Windows 11 oggi non è più lo stesso kernel di quando NT 3.1 fu rilasciato per la prima volta nel 1993. Ciò che Kirk ha davvero elogiato sono stati alcuni dei concetti architettonici di base quando è stato fondato NT, piuttosto che pensare che tutti i progetti di Windows moderno siano intrinsecamente superiori a Linux.

A giudicare dai risultati storici, Linux alla fine ha raggiunto una posizione nei campi dei server e del cloud computing che NT non è riuscita a raggiungere. La licenza aperta di Linux consente a qualsiasi organizzazione di modificare il kernel, eseguirlo su una varietà di hardware e inviare miglioramenti alla linea principale. La successiva comparsa di container, strumenti di sviluppo ed enormi ecosistemi come Android hanno ulteriormente rafforzato questo modello di sviluppo.

La cosa interessante è che negli ultimi anni Microsoft ha lavorato duramente per far sì che Windows eseguisse meglio Linux. Il sottosistema Windows per Linux continua a ricevere miglioramenti in termini di prestazioni e rete e Microsoft ha anche lanciato funzionalità come i contenitori WSL, che consentono agli utenti di eseguire contenitori Linux direttamente nell'ambiente Windows. Google ha anche iniziato ad aggiungere il supporto WSL ai propri strumenti di intelligenza artificiale.

Allo stesso tempo, Kirk ha menzionato anche BSD. Secondo lei, se oggi si ridisegnasse il kernel del sistema operativo, oltre a NT, potrebbe apparire anche un'architettura simile a BSD. Crede che la struttura complessiva di BSD sia relativamente ordinata e che abbia meccanismi di isolamento come le prigioni nei suoi primi giorni.

Le jail di FreeBSD possono limitare i file system, gli utenti e gli ambienti di rete visibili da un processo, mentre Capsicum è più vicino al modello di capacità enfatizzato da Kirk. Dopo essere entrato in modalità Capability, il processo non può accedere allo spazio dei nomi globale a piacimento e può solo utilizzare le autorizzazioni esplicitamente concesse a se stesso tramite i descrittori di file. È interessante notare che il progetto Capsicum è stato completato presso l'Università di Cambridge e ha ricevuto finanziamenti per la ricerca da Google.

Da questo punto di vista, ciò di cui Kirk sta realmente discutendo non è chi è migliore in tutti gli scenari, Windows o Linux, ma una questione più basilare: come il sistema operativo dovrebbe rappresentare e controllare i "permessi".

L'idea di NT è di lasciare che le risorse abbiano tipi chiari, allegare permessi di accesso alle risorse e controllarle e registrarle in modo uniforme dal sistema operativo il più possibile. Linux parte dalle basi più flessibili Unix e soddisfa le esigenze di diversi ambienti attraverso molteplici meccanismi che possono essere combinati. Nessuno dei due metodi da solo può garantire la sicurezza del sistema.

L'emergere degli agenti IA sta rendendo la questione ancora più importante. In passato la domanda più importante per i sistemi operativi era confermare “quale utente” sta eseguendo l'operazione; in futuro, dovrà rispondere ulteriormente a chi può rappresentare un agente AI, a quali risorse può accedere, per quanto tempo ha l’autorizzazione, quali operazioni può eseguire e se il sistema può dimostrare accuratamente ciò che ha fatto.

Windows NT non è diventato l'attore dominante nel mondo dei server e del cloud computing e quella posizione è stata infine presa da Linux. Tuttavia, sono trascorsi più di 30 anni dall'avvento di NT 3.1. Windows utilizza ancora i concetti di progettazione originali di oggetti, handle, token di accesso e ACL e Microsoft sta ora iniziando a utilizzare questi meccanismi per risolvere il problema dell'isolamento dei permessi degli agenti AI.

Pertanto, l'"Open NT" immaginato da Laurie Kirk potrebbe esistere solo nella storia immaginaria per sempre, ma man mano che i computer iniziano a svolgere attivamente sempre più compiti per gli esseri umani, un problema sempre più reale si trova ad affrontare tutti i sistemi operativi: quando il software inizia ad agire per conto degli esseri umani, fino a che punto dovremmo permettergli di arrivare?