Il modello di rilascio stabile del kernel Linux è iniziato nel 2005, quando si è 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 che le correzioni dei bug venissero apportate durante quei 2-3 mesi e le distribuzioni Linux trovavano difficile mantenere aggiornati i kernel senza feedback da parte della comunità del kernel. In generale, i tentativi di mantenere i singoli kernel sicuri e con le ultime correzioni di bug sono stati uno sforzo ampio e confuso da parte di molti individui diversi.
I rilasci stabili del kernel si basano direttamente sui rilasci di Linus Torvalds e vengono rilasciati 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 viene aggiunto un ulteriore numero. Ad esempio, il kernel 4.4 viene rilasciato da Linus, 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 viene solitamente abbreviata con il numero 4.4.y quando si fa riferimento ad un albero di rilascio del kernel stabile. Ogni albero di rilascio stabile del kernel è mantenuto 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, il precedente albero di rilascio stabile del kernel 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 diversi utenti di Linux desideravano che un kernel fosse supportato per più di pochi mesi. In risposta, è stata creata la versione del kernel LTS (Long Term Supported), 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 di 2 anni.
Al momento in cui scrivo, i kernel LTS sono le versioni 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y e 5.10.y. Ogni settimana viene rilasciato un nuovo kernel. 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. Informazioni su tutti i kernel stabili a lungo termine, chi ne è responsabile e per quanto tempo verranno mantenuti, possono essere trovate sulla pagina dei rilasci di kernel.org .
I rilasci del kernel LTS accettano in media 6-8 patch al giorno, mentre i normali rilasci del kernel stabile contengono 10-15 patch al giorno. Il numero di patch varia in base al rilascio in base all'ora corrente del rilascio del kernel di sviluppo corrispondente e ad altre variabili esterne. Più un kernel LTS è vecchio, meno patch sono applicabili poiché molte correzioni di bug recenti non sono rilevanti per i kernel più vecchi. Tuttavia, più un kernel è vecchio, più difficile è eseguire il backport delle modifiche necessarie per essere applicate, a causa delle modifiche nella base di codice. Pertanto, anche se potrebbe essere applicato un numero complessivo di patch inferiore, lo sforzo richiesto nel mantenere un kernel LTS è maggiore rispetto al mantenimento del normale kernel stabile.
Regole di patch stabili del kernel
Le regole su cosa 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 risolvere solo una cosa.
- È necessario risolvere qualcosa che è stato segnalato come un problema.
- Può essere un nuovo ID dispositivo o una stranezza per l'hardware, ma non aggiunge nuove funzionalità importanti.
- Deve già essere unito all'albero di Linus Torvalds.
L'ultima regola, "Deve già essere 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 aggiorni non dovrebbe mai vedere una regressione. Ciò 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 utenti che nessun aggiornamento romperà mai nulla di ciò che attualmente funziona in una versione precedente. Quella promessa è valida 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 Linux.
Questa promessa vale sia per gli aggiornamenti incrementali stabili del kernel, sia per gli aggiornamenti principali più ampi che avvengono ogni tre mesi. Tuttavia, la comunità del kernel può fare questa promessa solo per il codice che viene incorporato nell'albero del kernel Linux. Qualsiasi codice incorporato nel kernel di un dispositivo che non sia presente nelle versioni kernel.org è sconosciuto e le interazioni con esso non possono mai essere pianificate o addirittura prese in considerazione.
I dispositivi basati su Linux che dispongono di set di patch di grandi dimensioni possono presentare grossi problemi durante l'aggiornamento ai kernel più recenti, a causa dell'elevato numero di modifiche tra ogni versione (10-14 mila modifiche per versione). I patchset SoC sono particolarmente noti per avere problemi con l'aggiornamento ai kernel più recenti a causa delle loro grandi dimensioni e della pesante modifica del codice del kernel specifico dell'architettura e talvolta del core. Di conseguenza, la maggior parte dei fornitori di SoC stanno 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
Durante i 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 vengono determinate come legate alla sicurezza solo dopo che è trascorso molto tempo, quindi la comunità del kernel consiglia vivamente di prendere sempre tutte le correzioni di bug rilasciate.
Quando i problemi di sicurezza vengono segnalati alla comunità del kernel, vengono risolti il prima possibile e pubblicati pubblicamente nell'albero di sviluppo e nelle versioni stabili. Come descritto sopra, le modifiche non vengono quasi mai descritte come una "correzione di sicurezza", ma assomigliano piuttosto a qualsiasi altra correzione di bug del kernel. Questo viene fatto per consentire alle parti interessate di aggiornare i propri sistemi prima che chi ha segnalato il problema lo annunci.
Per dettagli sulla segnalazione dei bug di sicurezza alla comunità del kernel per risolverli e correggerli 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 generalmente rilasciati settimane, mesi e talvolta anni dopo che la correzione è stata incorporata nei 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 vengano presi dal produttore e distribuiti agli utenti dopo che test adeguati abbiano dimostrato che l'aggiornamento funziona bene. Ciò presenta diversi vantaggi:
- Le versioni sono state riviste dagli sviluppatori del kernel nel loro insieme, non nelle singole parti.
- È difficile, se non impossibile, determinare quali patch risolvono i problemi di "sicurezza" e quali no. Quasi ogni versione LTS contiene 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 daranno come risultato un albero del kernel che è impossibile unire correttamente con le future versioni upstream.