Linux è solidamente il sistema operativo di riferimento del mondo cloud e, più in generale, alla base della grande maggioranza dei servizi e delle applicazioni digitali di cui ci serviamo ogni giorno. È per questo che qualsiasi possibile sua evoluzione ha un impatto potenziale importante sul mercato e sulla società digitale, anche se magari i dibattiti collegati non arrivano alla cronaca di massa dell'IT, restando limitati agli utenti più tecnici.

In questo senso, nelle ultime settimane si è intensificato il confronto su un tema piuttosto di nicchia - almeno al momento - ma che si intreccia con altri temi invece di maggior risalto legati a Linux. In particolare al tema della sua sicurezza intrinseca, ossia alla "solidità" del cuore - il kernel - del sistema operativo.

La questione nel complesso non è nuova. Vari importanti incidenti di cybersecurity hanno ampiamente dimostrato che i threat actor sono più che capaci e pronti nello sfruttare qualsiasi vulnerabilità software. Parallelamente, i "buoni" sono meno capaci nel trovarle e risolverle, per vari motivi ampiamente noti che spaziano dalle difficoltà tecniche alla colpevole reticenza di molte software house commerciali coinvolte, per arrivare alla mancanza di normative adeguate in merito.

Tutto questo ha lentamente portato alla consapevolezza che la cybersecurity parte anche dalla solidità del codice software, la quale può essere raggiunta solo se si adottano procedure e modelli di sviluppo altrettanto solidi. E no, non si tratta di "agile vs waterfall" piuttosto che di DevSecOps o di "copiloti" di AI: questi ed altri solo componenti importanti ma, almeno per ora, accessori. È il processo in sé che deve essere adeguato.

Dove mettere mano

Ma come la mettiamo con il codice che già esiste? In alcuni casi - pensiamo al codice embedded di sistemi critici - è chiaro che va esaminato per evidenziare vulnerabilità ancora non sfruttate. Ma in generale è difficile trovare un equilibrio convincente tra la semplicità di non mettere mano al codice esistente, che pare funzionare, e il rischio che qualcosa di quel codice sia in effetti una potenziale falla cyber.

Il problema riguarda ovviamente anche Linux, e nessuno lo ha mai negato. Il kernel del sistema operativo chiave dell'odierna IT ha oltre 20 milioni di linee di codice C: spesso si dice che ogni mille linee di codice ci deve essere un qualche bug di programmazione, questo significa oltre 20 mila possibili (anche se non certi) bug. Una community di diverse migliaia di maintainer volontari lavora costantemente per evitarli ed eliminarli, ma potrebbe non bastare.

Di sicuro non basta per quegli enti governativi USA che hanno esplicitamente indicato di sostituire linguaggio "rischiosi" come C o C++ con altri più improntati alla sicurezza. Indicando in Rust un possibile (ed ennesimo) "miglior C". Cosa che ha scatenato l'ira anche un po' scomposta di una buona fetta della community tecnica di Linux.

Esiste da tempo un progetto - Rust for Linux - che mira a portare progressivamente Rust nel kernel di Linux. È un lavoro complesso che ora sembra giunto a un punto critico di stallo, perché le frizioni tra fan di Rust e difensori del buon vecchio C sembrano arrivate a una contrapposizione definitiva. I primi che partecipano al progetto Rust for Linux hanno bisogno di una certa collaborazione da parte dei maintainer del kernel, che però nicchiano o sono esplicitamente ostili. Per motivi tecnici certamente, ma anche per ragioni più filosofiche e - diciamolo - talvolta persino emotive.

Lato tecnico, l'opinione dei tradizionalisti è che Rust non presenti poi particolari vantaggi rispetto a C - o a qualsiasi altro linguaggio - quando si tratta di sviluppare per un ambito così particolare come il kernel di un sistema operativo. Qui lo scenario di sviluppo è "unsafe" quasi per definizione, l'unica soluzione è sviluppare bene e con attenzione. Il che si può fare tranquillamente come si è fatto sinora.

Lato "sensibilità personali", il messaggio "si può e si deve sviluppare in maniera più solida" è stato interpretato da alcuni importanti maintainer come "non avete fatto un buon lavoro e dovete evolvere". Un messaggio poco gradito e che si è innestato sul confronto "Rust vs C" già spinoso prima, e abbondantemente, di suo. Piccolezze, per chi non vive il mondo Linux più tecnico. Questioni chiave per molti che invece ne fanno parte. E ora siamo un po' ad un muro contro muro che non fa bene a nessuno.

Nuove strade da esplorare

Il dubbio che si possono porre gli utenti aziendali di Linux, probabilmente poco interessati alle diatribe della community, è se questo contrasto - insieme alle crescenti difficoltà del progetto Rust for Linux - avrà impatti importanti sulla cybersecurity di Linux e delle sue evoluzioni. L'impressione è che poco cambi a breve ed a medio termine, ma sviluppi interessanti possano aversi più a lungo termine.

L'interfaccia grafica di Redox OS, sistema operativo a microkernel basato su Rust

Se la community Rust, con il supporto magari di qualche grande software house, deciderà che "riscrivere" Linux in Rust è un esercizio troppo difficile politicamente, potrebbe decidere di puntare a un nuovo sistema operativo Linux-compatibile ma basato su Rust. Idee in questo senso sono già state espresse da più parti.

In effetti un progetto simile esiste già - Redox OS - ma segue un approccio diverso da Linux: è un sistema operativo basato sul concetto di microkernel, mentre Linux si basa su un kernel monolitico. Una compatibilità completa e trasparente quindi è impossibile, al momento. E Redox OS è comunque solo in una fase iniziale di sviluppo.

Un "Rust Linux" vero e proprio avrebbe una natura diversa, con una architettura analoga a Linux ma codice in larga prevalenza Rust. In teoria potrebbe nascere nel giro di relativamente poco - un paio d'anni, anche meno - per affermarsi come un Linux "safe" per applicazioni specifiche. E poi magari diffondersi come neo-Linux per chi è interessato alla solidità del codice di base. È solo una ipotesi, ma comunque interessante.