Il modello di release stabili del kernel Linux è stato avviato nel 2005, quando è stato stabilito che il modello di sviluppo del kernel esistente (una nuova release ogni 2-3 mesi) non soddisfaceva le esigenze della maggior parte degli utenti. Gli utenti volevano che le correzioni dei bug venissero apportate durante questi 2-3 mesi e le distribuzioni Linux hanno avuto difficoltà a mantenere aggiornati i kernel senza feedback dalla community del kernel. In generale, i tentativi di mantenere i singoli kernel sicuri e con gli ultimi bugfix sono stati un impegno smisurato e confuso da parte di molte persone diverse.
Le release del kernel stabili si basano direttamente sulle release di Linus Torvalds e vengono rilasciate ogni settimana circa, a seconda di vari fattori esterni (stagione, patch disponibili, carico di lavoro dei manutentori e così via). La numerazione delle release stabili inizia con il numero della release del kernel e alla fine viene aggiunto un altro numero. Ad esempio, il kernel 4.4 viene rilasciato da Linus e quindi le release del kernel stabile basate su questo kernel sono numerate 4.4.1, 4.4.2, 4.4.3 e così via. Questa sequenza viene solitamente abbreviata con il numero 4.4.y quando si fa riferimento a una struttura di release del kernel stabile. Ogni albero delle release del kernel stabile è gestito da un singolo sviluppatore del kernel, che è responsabile della scelta delle patch necessarie per la release e della gestione del processo di revisione/release.
I kernel stabili vengono mantenuti per tutta la durata dell'attuale ciclo di sviluppo. Dopo che Linus rilascia un nuovo kernel, l'albero delle release del kernel stabile precedente viene interrotto e gli utenti devono passare al kernel rilasciato più recente.
Kernel stabili a lungo termine
Dopo un anno di questa nuova procedura di rilascio stabile, è stato stabilito che molti diversi utenti di Linux volevano che un kernel fosse supportato per più di qualche mese. In risposta, è stata creata la versione del kernel con assistenza a lungo termine (LTS), con il primo kernel LTS (2.6.16) rilasciato nel 2006. Da allora, un nuovo kernel LTS viene selezionato una volta all'anno e la community del kernel lo gestisce per un minimo di 2 anni.
Al momento della stesura di questo articolo, i kernel LTS sono le release 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y e 5.10.y. Viene rilasciato un nuovo kernel ogni settimana. A causa delle esigenze di alcuni utenti e distribuzioni, alcuni kernel meno recenti vengono mantenuti dagli sviluppatori con un ciclo di rilascio più lento. Puoi trovare informazioni su tutti i kernel stabili a lungo termine, su chi ne è responsabile e sul periodo di tempo per cui vengono mantenuti nella pagina kernel.org/releases.
Le release del kernel LTS accettano in media 6-8 patch al giorno, mentre le release del kernel stabile normali contengono 10-15 patch al giorno. Il numero di patch oscilla in base alla release, in base all'ora corrente della release del kernel di sviluppo corrispondente e ad altre variabili esterne. Più vecchio è un kernel LTS, meno patch sono applicabili, poiché molti bugfix recenti non sono pertinenti per i kernel meno recenti. Tuttavia, più vecchio è il kernel, più è difficile eseguire il backport delle modifiche da applicare a causa delle modifiche nella base di codice. Pertanto, anche se potrebbe essere applicato un numero inferiore di patch complessive, l'impegno necessario per la manutenzione di un kernel LTS è maggiore rispetto a quello necessario per la manutenzione del normale kernel stabile.
Regole per le patch del kernel stabile
Le regole relative a ciò che può essere aggiunto a una release del kernel stabile sono rimaste quasi identiche dalla loro introduzione e sono riassunte di seguito:
- Deve essere chiaramente corretto e testato.
- Non deve superare le 100 righe.
- Devi correggere solo un aspetto.
- Deve essere risolto un problema segnalato.
- Può essere un nuovo ID dispositivo o una peculiarità per l'hardware, ma non aggiunge nuove funzionalità importanti.
- Deve essere già unito all'albero di Linus Torvalds.
L'ultima regola, "Deve essere già unita al tree di Linus Torvalds", impedisce alla community del kernel di perdere le correzioni. La community non vuole mai che una correzione venga inserita in una release del kernel stabile che non sia già presente nell'albero di Linus Torvalds, in modo che chiunque eseguisse l'upgrade non debba mai riscontrare una regressione. In questo modo si evitano molti problemi che possono verificarsi in altri progetti che gestiscono un ramo stabile e di sviluppo.
Aggiornamenti del kernel
La community del kernel Linux ha promesso alla sua base di utenti che nessun upgrade romperà mai nulla che funzioni in una release precedente. Questa promessa è ancora valida oggi. Le regressioni si verificano, ma si tratta di bug con la priorità più alta e vengono corretti rapidamente oppure la modifica che ha causato la regressione viene ripristinata rapidamente dall'albero del kernel di Linux.
Questa promessa vale sia per gli aggiornamenti incrementali del kernel stabile sia per gli aggiornamenti principali più grandi che vengono eseguiti ogni tre mesi. Tuttavia, la comunità del kernel può fare questa promessa solo per il codice unito all'albero del kernel di Linux. Qualsiasi codice unito al kernel di un dispositivo che non è presente nelle release di kernel.org è sconosciuto e le interazioni con questo codice non possono mai essere pianificate o prese in considerazione.
I dispositivi basati su Linux con set di patch di grandi dimensioni possono riscontrare problemi importanti durante l'aggiornamento ai kernel più recenti, a causa del numero elevato di modifiche tra ogni release (10-14 mila modifiche per release). I set di patch SoC sono noti soprattutto per i problemi di aggiornamento ai kernel più recenti a causa delle loro dimensioni elevate e delle pesanti modifiche al codice del kernel specifico dell'architettura e, a volte, di quello di base. Di conseguenza, la maggior parte dei fornitori di SoC sta iniziando a standardizzare l'utilizzo delle release LTS per i propri dispositivi, consentendo a questi dispositivi di ricevere aggiornamenti di bug e sicurezza direttamente dalla community del kernel Linux.
Sicurezza
Quando rilascia il kernel, la community del kernel Linux non dichiara quasi mai modifiche specifiche come correzioni di sicurezza. Questo è dovuto al problema di base della difficoltà di determinare se una correzione di bug è o meno una correzione di sicurezza al momento della creazione. Inoltre, molte correzioni di bug vengono considerate correlate alla sicurezza solo dopo molto tempo, pertanto la community del kernel consiglia vivamente di applicare sempre tutte le correzioni di bug rilasciate.
Quando i problemi di sicurezza vengono segnalati alla community del kernel, vengono corretti il prima possibile e inviati pubblicamente alla struttura di sviluppo e alle release stabili. Come descritto sopra, le modifiche non vengono quasi mai descritte come "correzione di sicurezza", ma sembrano piuttosto una normale correzione di bug per il kernel. Questo avviene per consentire alle parti interessate di aggiornare i propri sistemi prima che il segnalatore del problema lo annunci.
Per informazioni dettagliate su come segnalare i bug di sicurezza alla community del kernel per farli risolvere e correggere il prima possibile, consulta la sezione relativa ai bug di sicurezza nella Guida per gli utenti e gli amministratori del kernel Linux all'indirizzo www.kernel.org.
Poiché i bug di sicurezza non vengono annunciati al pubblico dal team del kernel, i numeri CVE per i problemi relativi al kernel di Linux vengono in genere rilasciati settimane, mesi e talvolta anni dopo l'unione della correzione ai branch stabili e di sviluppo.
Mantieni un sistema sicuro
Quando esegui il deployment di un dispositivo che utilizza Linux, ti consigliamo vivamente di fare in modo che tutti gli aggiornamenti del kernel LTS vengano eseguiti dal produttore e inviati agli utenti dopo che test adeguati hanno dimostrato che l'aggiornamento funziona correttamente. Questo approccio presenta numerosi vantaggi:
- Le release sono state esaminate dagli sviluppatori del kernel nel loro insieme, non in singole parti.
- È difficile determinare quali patch risolvono i problemi di "sicurezza" e quali no. Quasi ogni release LTS contiene almeno una correzione di sicurezza nota e molte altre "sconosciute".
- Se i test mostrano un problema, la community di sviluppatori del kernel reagisce rapidamente per risolverlo.
- I tentativi di filtrare solo le modifiche che esegui generano un albero del kernel impossibile da unire correttamente con le release upstream future.