Il modello di rilascio stabile del kernel Linux è iniziato nel 2005, quando è stato stabilito che il modello di sviluppo del kernel esistente (una nuova versione ogni 2-3 mesi) non soddisfaceva le esigenze della maggior parte degli utenti. Gli utenti volevano correzioni di bug durante quei 2-3 mesi e le distribuzioni Linux hanno trovato difficile mantenere aggiornati i kernel senza il feedback della comunità del kernel. In generale, i tentativi di mantenere i singoli kernel al sicuro e con le ultime correzioni di bug sono stati uno sforzo grande e confuso da parte di molte persone diverse.
Le versioni stabili del kernel si basano direttamente sulle versioni di Linus Torvalds e vengono rilasciate ogni settimana circa, a seconda di vari fattori esterni (periodo dell'anno, patch disponibili, carico di lavoro del manutentore, ecc.). La numerazione delle versioni stabili inizia con il numero della versione del kernel e alla fine di essa viene aggiunto un numero aggiuntivo. Ad esempio, il kernel 4.4 è rilasciato da Linus, e quindi le versioni stabili del kernel basate su questo kernel sono numerate 4.4.1, 4.4.2, 4.4.3 e così via. Questa sequenza è solitamente abbreviata con il numero 4.4.y quando si fa riferimento a un albero di rilascio del kernel stabile. Ogni albero di rilascio del kernel stabile è gestito da un singolo sviluppatore del kernel, che è responsabile della scelta delle patch necessarie per il rilascio e della gestione del processo di revisione/rilascio.
I kernel stabili vengono mantenuti per la durata dell'attuale ciclo di sviluppo. Dopo che Linus ha rilasciato un nuovo kernel, l'albero di rilascio 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 questo nuovo processo di rilascio stabile, è stato stabilito che molti utenti diversi di Linux volevano che un kernel fosse supportato per più di pochi mesi. In risposta, è stata creata la versione del kernel Long Term Supported (LTS), con il primo kernel LTS (2.6.16) rilasciato nel 2006. Da allora, un nuovo kernel LTS è stato selezionato una volta all'anno e la comunità del kernel mantiene quel kernel per un minimo 2 anni.
Al momento della stesura di questo documento, i kernel LTS sono le versioni 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.ye 5.10.y. Un nuovo kernel viene rilasciato settimanalmente. A causa delle esigenze di alcuni utenti e distribuzioni, alcuni kernel più vecchi aggiuntivi vengono mantenuti dagli sviluppatori del kernel con un ciclo di rilascio più lento. Le informazioni su tutti i kernel stabili a lungo termine, chi ne è responsabile e per quanto tempo saranno mantenuti, possono essere trovate nella pagina dei rilasci di kernel.org .
Il kernel LTS rilascia in media 6-8 patch accettate al giorno, mentre le normali versioni del kernel stabile contengono 10-15 patch al giorno. Il numero di patch fluttua per release data l'ora corrente della corrispondente release del kernel di sviluppo e altre variabili esterne. Più vecchio è un kernel LTS, meno patch sono applicabili ad esso poiché molte recenti correzioni di bug non sono rilevanti per i kernel più vecchi. Tuttavia, più vecchio è un kernel, più difficile è eseguire il backport delle modifiche che devono essere applicate, a causa delle modifiche nella base di codice. Quindi, mentre potrebbe esserci un numero inferiore di patch complessive applicate, lo sforzo necessario per mantenere un kernel LTS è maggiore rispetto al mantenimento del normale kernel stabile.
Regole di patch del kernel stabili
Le regole per ciò che può essere aggiunto a una versione stabile del kernel sono rimaste quasi identiche dalla sua introduzione e sono riassunte di seguito:
- Deve essere ovviamente corretto e testato.
- Non deve essere più grande di 100 righe.
- Deve aggiustare solo una cosa.
- Deve risolvere qualcosa che è stato segnalato come un problema.
- Può essere un nuovo ID dispositivo o una stranezza per l'hardware, ma non aggiungere nuove importanti funzionalità.
- Deve già essere unito all'albero di Linus Torvalds.
L'ultima regola, "Deve essere già unito all'albero di Linus Torvalds", impedisce alla comunità del kernel di perdere le correzioni. La comunità non vuole mai che una correzione entri in una versione stabile del kernel che non sia già nell'albero di Linus Torvalds, in modo che chiunque esegua l'aggiornamento non dovrebbe mai vedere una regressione. Questo previene molti problemi che possono avere altri progetti che mantengono un ramo stabile e di sviluppo.
Aggiornamenti del kernel
La comunità del kernel Linux ha promesso alla sua base di utenti che nessun aggiornamento interromperà mai nulla di ciò che sta attualmente funzionando in una versione precedente. Quella promessa vale ancora oggi. Le regressioni si verificano, ma questi sono i bug con la priorità più alta e vengono risolti rapidamente, oppure la modifica che ha causato la regressione viene rapidamente ripristinata dall'albero del kernel di Linux.
Questa promessa vale sia per gli aggiornamenti incrementali stabili del kernel, sia per gli aggiornamenti principali più grandi che si verificano ogni tre mesi. Tuttavia, la comunità del kernel può solo fare questa promessa per il codice che è unito all'albero del kernel di Linux. Qualsiasi codice che viene unito al kernel di un dispositivo che non è nelle versioni di kernel.org è sconosciuto e le interazioni con esso non possono mai essere pianificate, o addirittura considerate.
I dispositivi basati su Linux che hanno set di patch di grandi dimensioni possono avere grossi problemi durante l'aggiornamento a kernel più recenti, a causa dell'elevato numero di modifiche tra ogni versione (10-14 mila modifiche per versione). È noto in particolare che i patchset SoC presentano problemi con l'aggiornamento ai kernel più recenti a causa delle loro grandi dimensioni e delle pesanti modifiche del codice del kernel specifico dell'architettura e talvolta di base. Di conseguenza, la maggior parte dei fornitori di SoC sta iniziando a standardizzare l'utilizzo delle versioni LTS per i propri dispositivi, consentendo a tali dispositivi di ricevere bug e aggiornamenti di sicurezza direttamente dalla comunità del kernel Linux.
Sicurezza
Quando si eseguono rilasci del kernel, la comunità del kernel Linux non dichiara quasi mai modifiche specifiche come correzioni di sicurezza . Ciò è dovuto al problema di base della difficoltà nel determinare se una correzione di bug è una correzione di sicurezza o meno al momento della creazione. Inoltre, molte correzioni di bug sono determinate per essere correlate alla sicurezza solo dopo che è trascorso molto tempo, quindi la comunità del kernel raccomanda vivamente di prendere sempre tutte le correzioni di bug che vengono rilasciate.
Quando i problemi di sicurezza vengono segnalati alla comunità del kernel, vengono risolti il prima possibile e inviati pubblicamente all'albero di sviluppo e alle versioni stabili. Come descritto sopra, le modifiche non sono quasi mai descritte come una "correzione di sicurezza", ma assomigliano a qualsiasi altra correzione di bug per il kernel. Questo viene fatto per consentire alle parti interessate la possibilità di aggiornare i propri sistemi prima che il segnalatore del problema lo annunci.
Per i dettagli sulla segnalazione di bug di sicurezza alla comunità del kernel per risolverli e risolverli il prima possibile, fare riferimento a Bug di sicurezza nella Guida per l'utente e l'amministratore del kernel Linux su 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 Linux vengono solitamente rilasciati settimane, mesi e talvolta anni dopo che la correzione è stata unita ai rami stabile e di sviluppo.
Mantenere un sistema sicuro
Quando si distribuisce un dispositivo che utilizza Linux, si consiglia vivamente che tutti gli aggiornamenti del kernel LTS siano presi dal produttore e inviati ai propri utenti dopo che un test adeguato ha dimostrato che l'aggiornamento funziona correttamente. Questo ha diversi vantaggi:
- Le versioni sono state riviste dagli sviluppatori del kernel nel loro insieme, non in singole parti.
- È difficile, se non impossibile, determinare quali patch risolvono i problemi di "sicurezza" e quali no. Quasi tutte le versioni LTS contengono almeno una correzione di sicurezza nota e molte ancora "sconosciute".
- Se il test mostra un problema, la comunità degli sviluppatori del kernel reagirà rapidamente per risolvere il problema.
- I tentativi di filtrare solo le modifiche eseguite risulteranno in un albero del kernel che è impossibile unire correttamente con future versioni upstream.