Linux continua a spingersi in territori nei quali un errore software non significa semplicemente chiudere e riaprire un programma. Il progetto ELISA, nato per favorire l'utilizzo di Linux e del Software Libero nei sistemi safety-critical, ha annunciato l'ingresso nel proprio ecosistema di Cregit e stress-ng, due strumenti molto differenti ma complementari: il primo permette di ricostruire con maggiore precisione la storia e la provenienza del codice, mentre il secondo sottopone hardware e software a centinaia di differenti condizioni di stress per verificarne comportamento, stabilità e affidabilità.
La notizia può apparire estremamente specialistica, ma riguarda in realtà una trasformazione che sta avvenendo da tempo e che progressivamente porta Linux molto lontano dal computer sul quale lo abbiamo conosciuto.
Automobili, macchinari industriali, sistemi ferroviari, dispositivi embedded e infrastrutture sempre più complesse utilizzano quantità crescenti di software e, in molti di questi settori, Linux rappresenta ormai una piattaforma tecnologica particolarmente importante. Quando però un sistema informatico entra in un'automobile, controlla un macchinario industriale o partecipa al funzionamento di un'infrastruttura dalla quale dipende la sicurezza delle persone, non possiamo limitarci alla constatazione che il programma sembri funzionare correttamente.
Dobbiamo poter costruire evidenze che permettano di dimostrare perché riteniamo che quel sistema sia sufficientemente affidabile.
È precisamente il territorio nel quale opera ELISA, Enabling Linux In Safety Applications, progetto ospitato dalla Linux Foundation che non cerca di realizzare una speciale distribuzione Linux dichiarata genericamente "sicura", ma lavora invece alla definizione di strumenti, metodi, processi e documentazione attraverso i quali un determinato sistema basato su Linux possa affrontare i percorsi di verifica e certificazione richiesti negli ambienti safety-critical.
La distinzione è fondamentale perché non esiste un pulsante attraverso il quale trasformare Linux in un sistema certificato per qualsiasi impiego critico. Un sistema deve essere valutato nel proprio contesto, tenendo conto dell'hardware, della configurazione, dei componenti utilizzati, delle funzioni che deve svolgere e soprattutto delle conseguenze che potrebbe produrre un eventuale malfunzionamento.
L'ingresso di Cregit e stress-ng nell'ecosistema ELISA deve essere letto proprio in questa prospettiva.
Cregit affronta un problema che diventa particolarmente interessante quando lavoriamo con un progetto enorme e sviluppato nell'arco di decenni come il kernel Linux: comprendere da dove provenga realmente una determinata parte del codice e come sia cambiata nel tempo.
Git mette già a disposizione strumenti come git blame, attraverso i quali possiamo individuare il commit e l'autore associati a determinate righe di un file, ma la storia reale del software è spesso più complessa di quanto possa essere rappresentato semplicemente osservando l'ultima persona che ha modificato una riga.
Il codice viene spostato, riformattato, rifattorizzato e modificato progressivamente, mentre una singola riga può contenere elementi provenienti da contributi differenti.
Cregit utilizza quindi un'analisi a livello di token, cercando di ricostruire con maggiore precisione l'evoluzione delle singole parti del codice e producendo visualizzazioni attraverso le quali è possibile esplorarne provenienza, contributori e trasformazioni.
In un normale progetto software questa possibilità può essere utile per comprendere chi conosca meglio una determinata componente oppure per ricostruire la ragione di una modifica; in un sistema destinato a funzioni critiche assume però un significato ancora più importante, perché la tracciabilità diventa parte del processo attraverso il quale cerchiamo di costruire evidenze sulla qualità e sull'evoluzione del software.
Sapere che una funzione esiste oggi non è sempre sufficiente: può essere necessario capire quando sia stata introdotta, quali problemi abbia corretto, quali modifiche abbia attraversato e quali persone o gruppi abbiano lavorato su quella parte del sistema.
È un approccio particolarmente interessante se consideriamo la natura stessa del kernel Linux, che non nasce attraverso un processo centralizzato nel quale una singola azienda progetta ogni componente secondo un unico piano, ma attraverso una collaborazione distribuita che coinvolge migliaia di sviluppatori, imprese e organizzazioni.
Questa enorme diversità costituisce una delle principali forze del progetto, ma quando Linux viene utilizzato in contesti regolamentati crea anche una domanda difficile: come trasformiamo decenni di sviluppo comunitario in informazioni strutturate che possano essere utilizzate all'interno di un processo di assurance e certificazione?
Cregit prova a fornire una parte degli strumenti necessari per rispondere.
Il secondo progetto, stress-ng, affronta invece il problema da una prospettiva completamente differente.
Sviluppato da Colin Ian King, stress-ng è uno strumento libero progettato per sottoporre un sistema Linux a una quantità enorme di differenti carichi di lavoro, esercitando processore, memoria, cache, filesystem, scheduler, dispositivi, chiamate di sistema e numerose altre componenti.
Non si limita quindi a "far lavorare molto la CPU", come potrebbe suggerire superficialmente il termine stress test, ma mette a disposizione centinaia di differenti stressor, ciascuno pensato per esercitare specifiche parti del sistema.
L'obiettivo può essere verificare stabilità e prestazioni, individuare regressioni oppure far emergere comportamenti anomali che in condizioni normali potrebbero manifestarsi soltanto molto raramente.
È una strategia particolarmente importante perché molti problemi informatici non compaiono durante il normale utilizzo.
Un sistema può funzionare perfettamente per giorni e mostrare un errore soltanto quando una particolare sequenza di eventi avviene contemporaneamente, quando la memoria è sottoposta a una determinata pressione oppure quando più processi competono per la stessa risorsa.
Gli strumenti di stress cercano deliberatamente di portare il sistema in condizioni difficili, non perché quelle condizioni debbano necessariamente verificarsi continuamente nel mondo reale, ma perché un comportamento fragile diventa più facile da individuare quando smettiamo di trattare gentilmente il sistema che vogliamo verificare.
Cregit e stress-ng affrontano quindi due lati differenti dello stesso problema.
Il primo guarda prevalentemente indietro, cercando di comprendere la storia e la provenienza del codice; il secondo guarda al suo comportamento durante l'esecuzione, sottoponendo il sistema a condizioni progettate per far emergere eventuali debolezze.
È proprio questa complementarità ad aver spinto ELISA a integrarli nel proprio ecosistema.
Ma la notizia permette soprattutto di affrontare una questione più generale sul Software Libero.
Quando diciamo che il codice sorgente è disponibile, infatti, abbiamo compiuto un passo fondamentale verso la trasparenza, ma non abbiamo automaticamente dimostrato che quel codice sia corretto.
Software Libero non significa software privo di errori.
Significa piuttosto che possediamo libertà e strumenti che rendono possibile studiarlo, sottoporlo a verifiche indipendenti, ricostruirne la storia, modificarlo e condividere pubblicamente le correzioni.
In un sistema safety-critical questa differenza diventa particolarmente evidente.
Non possiamo affermare che Linux sia sicuro semplicemente perché il codice è aperto, così come non possiamo affermare che un programma proprietario sia necessariamente insicuro perché il codice non è pubblico; possiamo però osservare che un processo aperto rende possibile costruire una base di conoscenza condivisa nella quale analisi, strumenti, test e metodologie possono essere esaminati da soggetti differenti.
Ed è proprio questa verificabilità uno dei contributi più importanti che il Software Libero può portare nei sistemi critici.
Se un'impresa afferma che il proprio sistema è sicuro, possiamo naturalmente chiedere documentazione e risultati dei test; quando però anche gli strumenti utilizzati per produrre quelle evidenze sono liberi, altre organizzazioni possono riprodurre parte del processo, controllarne il funzionamento e contribuire a migliorarlo.
La fiducia può quindi essere progressivamente trasformata in verifica.
Questo principio assume un valore particolare in settori nei quali per molti anni il Software Libero è stato considerato con diffidenza proprio perché il suo modello di sviluppo appariva troppo distribuito e poco controllabile rispetto ai processi tradizionali dell'ingegneria safety-critical.
Il kernel Linux non viene infatti progettato dall'inizio seguendo esclusivamente un singolo standard di sicurezza funzionale. Nasce come sistema operativo general purpose e viene continuamente modificato da una comunità enorme per rispondere alle esigenze di server, desktop, supercomputer, smartphone, dispositivi embedded e innumerevoli altre piattaforme.
Portarlo in un ambiente safety-critical significa quindi affrontare un problema diverso rispetto alla costruzione da zero di un piccolo sistema progettato esclusivamente per una funzione certificata.
Occorre comprendere quali componenti vengono realmente utilizzati, costruire requisiti, associare test a quei requisiti, raccogliere evidenze, tracciare modifiche e dimostrare che il comportamento della configurazione scelta soddisfi gli obiettivi richiesti.
ELISA lavora precisamente alla costruzione di questo ponte tra il modello aperto dello sviluppo Linux e il mondo estremamente rigoroso della sicurezza funzionale.
L'aggiunta di Cregit e stress-ng amplia ora la cassetta degli attrezzi attraverso la quale questa comunità può affrontare il problema.
C'è inoltre un aspetto che riguarda direttamente l'autonomia tecnologica.
Automobili, treni, macchinari industriali e infrastrutture moderne dipendono sempre più dal software e, quando quel software diventa inseparabile dal prodotto fisico, chi controlla il codice acquisisce inevitabilmente una parte del controllo sull'intero sistema.
La possibilità di utilizzare tecnologie libere in questi settori può quindi ridurre la dipendenza da piattaforme proprietarie, ma soltanto se il Software Libero riesce contemporaneamente a soddisfare requisiti di affidabilità, manutenzione e certificazione estremamente elevati.
Non basta sostenere che Linux sia libero e quindi preferibile.
Bisogna dimostrare che possa svolgere il lavoro richiesto.
Ed è forse proprio questa la parte più interessante del progetto ELISA: non chiede di fidarsi di Linux perché è Software Libero, ma cerca di costruire strumenti attraverso i quali Linux possa essere verificato proprio come qualsiasi altra tecnologia destinata a funzioni critiche.
È un atteggiamento molto diverso dalla contrapposizione ideologica tra software proprietario e software libero, perché riconosce che la libertà del codice non sostituisce l'ingegneria, i test, la documentazione e la responsabilità.
Li rende però condivisibili.
Un test sviluppato da una comunità può essere utilizzato da più imprese; una metodologia può essere discussa pubblicamente; un problema individuato da un'azienda può produrre una correzione che torna al progetto upstream e diventa disponibile anche per tutti gli altri utilizzatori.
È uno dei grandi vantaggi potenziali del modello collaborativo: la sicurezza smette almeno in parte di essere un patrimonio duplicato all'interno di ogni singola azienda e può diventare conoscenza comune.
Naturalmente rimangono enormi difficoltà e la stessa ELISA precisa esplicitamente di non produrre una "Linux sicura" pronta per essere installata, né di poter garantire automaticamente che un sistema costruito utilizzando i propri strumenti soddisfi i requisiti necessari.
La responsabilità rimane nelle mani di chi progetta e certifica il prodotto concreto.
Ma proprio questa cautela rende il lavoro più credibile.
L'obiettivo non è applicare un'etichetta di sicurezza a Linux, ma costruire gradualmente processi attraverso i quali un sistema specifico possa dimostrare le proprie caratteristiche.
L'ingresso di Cregit e stress-ng nell'ecosistema ELISA può quindi sembrare una piccola notizia destinata esclusivamente agli sviluppatori del kernel, ma racconta in realtà qualcosa di molto più grande: Linux sta entrando in settori nei quali la libertà del codice deve imparare a convivere con la necessità di produrre prove rigorose sul comportamento del software.
Per decenni abbiamo difeso il Software Libero sostenendo che il diritto di leggere il codice fosse essenziale.
Nei sistemi critici dobbiamo compiere il passo successivo.
Non basta poterlo leggere: dobbiamo poter ricostruire come è arrivato fin lì, sapere chi lo ha modificato, sottoporlo a condizioni estreme, collegare requisiti e test e produrre evidenze verificabili sul suo comportamento.
Cregit e stress-ng lavorano su due parti di questo problema e, entrando nell'ecosistema ELISA, diventano elementi di un tentativo molto più ambizioso.
Portare Linux nei sistemi dai quali può dipendere anche la sicurezza delle persone senza chiedere a nessuno un atto di fede, ma costruendo gli strumenti necessari per trasformare la fiducia nel Software Libero in conoscenza verificabile.