Il modello di release stabile del kernel Linux è iniziato nel 2005, quando è stato determinato il modello di sviluppo del kernel esistente (una nuova release ogni 2-3 mesi) non soddisfano le esigenze della maggior parte degli utenti. Gli utenti volevano correzioni di bug durante quelle 2-3 mesi e le distribuzioni Linux hanno avuto difficoltà a mantenere aggiornati i kernel senza il feedback della community del kernel. In generale, cerca di mantenere singoli kernel sicuri e con le ultime correzioni di bug era un impegno da parte di persone diverse.
Le release stabili del kernel sono basate direttamente sulla versione rilasciate e sono e rilasciate ogni settimana circa, in base a vari fattori esterni (periodo dell'anno, le patch disponibili, il carico di lavoro del gestore e così via). La numerazione delle risorse di release inizia con il numero della release del kernel e un numero aggiuntivo viene aggiunto alla fine. Ad esempio, il kernel 4.4 viene rilasciato da Linus e allora le release stabili del kernel basate su questo kernel sono numerate 4.4.1, 4.4.2, 4.4.3 e così via. Questa sequenza è solitamente accorciata con il numero 4.4.y quando che fa riferimento a un albero di release del kernel stabile. Ogni albero di release del kernel stabile gestito da un singolo sviluppatore kernel, responsabile della scelta le patch necessarie per il rilascio e per la 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, viene usato il precedente albero di release del kernel stabile. e gli utenti devono passare al kernel più recente rilasciato.
Kernel stabili a lungo termine
Dopo un anno di questo nuovo processo di rilascio stabile, è stato stabilito che molti diversi utenti di Linux volevano che un kernel fosse supportato per più tempo rispetto a un alcuni mesi. In risposta, la release del kernel LTS (Long Term Support) è stata creato, con il primo kernel LTS (2.6.16) rilasciato nel 2006. Da allora, è stata introdotta una nuova Il kernel LTS è stato selezionato una volta all'anno e la community del kernel mantiene che per almeno 2 anni.
Al momento della stesura di questo articolo, i kernel LTS sono 4.4.y, 4.9.y, 4.14.y, Release 4.19.y, 5.4.y e 5.10.y. Ogni settimana viene rilasciato un nuovo kernel. A causa di le esigenze di alcuni utenti e distribuzioni, alcuni kernel più vecchi gestito dagli sviluppatori del kernel con un ciclo di rilascio più lento. Informazioni su tutti i kernel stabili a lungo termine, chi li gestisce e per quanto tempo disponibile nella kernel.org di release.
Il kernel LTS rilascia in media 6-8 patch accettate al giorno, mentre le release stabili del kernel contengono 10-15 patch al giorno. Il numero di patch varia a seconda della release in base all'ora corrente dello sviluppo corrispondente della release del kernel e altre variabili esterne. Il meno recente è un kernel LTS, sono applicabili meno patch, in quanto molte correzioni di bug recenti non sono con kernel meno recenti. Tuttavia, più un kernel è vecchio, più è difficile eseguire il backporting modifiche necessarie da applicare a causa delle modifiche al codebase. Quindi... mentre il numero di patch complessive potrebbe essere inferiore, l'impegno coinvolto nel mantenimento di un kernel LTS è maggiore che mantenere la normale un kernel stabile.
Regole patch stabili del kernel
Le regole relative a ciò che può essere aggiunto a una release stabile del kernel sono rimaste sono quasi identici dalla sua introduzione e sono riassunti di seguito:
- Deve essere palesemente corretto e testato.
- Non deve essere più grande di 100 righe.
- Deve correggere solo un problema.
- Deve risolvere un problema segnalato.
- Può essere un nuovo ID dispositivo o un peculiare per l'hardware, ma non aggiungerne di nuove importanti. funzionalità.
- Deve già essere unita a quella di Linus Torvalds albero di Natale.
L'ultima regola, "Deve essere già unita ai Linus Torvalds", albero", impedisce alla community del kernel di perdere correzioni. La community non vuole mai trovare una soluzione in una release del kernel stabile che non sia già presente nella versione di Linus Torvalds. albero, quindi che chiunque esegua l'upgrade non dovrebbe mai vedere una regressione. Ciò impedisce a molti problemi che altri progetti che mantengono un ramo stabile e di sviluppo possono avere.
Aggiornamenti del kernel
La community del kernel Linux ha promesso alla sua base utenti che nessun upgrade romperà tutto ciò che funzionava in una release precedente. Questo promessa è ancora valida oggi. Le regressioni si verificano, ma sono le più alte di priorità e che vengono risolti rapidamente, oppure la modifica che ha causato la regressione viene rapidamente ripristinata dalla struttura del kernel Linux.
Questa promessa vale sia per gli aggiornamenti stabili incrementali del kernel, come nonché i principali aggiornamenti più importanti che vengono eseguiti ogni tre mesi. Tuttavia, la community del kernel può fare questa promessa solo per il codice che viene unito del kernel Linux. Il codice unito al kernel di un dispositivo che non è le release di kernel.org sono sconosciute e e le interazioni con quest'ultimo non possono mai essere pianificate o prese in considerazione.
I dispositivi basati su Linux che dispongono di set di patch di grandi dimensioni possono presentare problemi gravi quando aggiornamento ai kernel più recenti, a causa dell'elevato numero di modifiche tra (10-14.000 modifiche per release). I set di patch SoC sono particolarmente noti avere problemi con l'aggiornamento ai kernel più recenti a causa delle loro grandi dimensioni modifica specifica dell'architettura e, a volte, del codice kernel. Come risultato, la maggior parte dei fornitori di SoC sta iniziando a standardizzare l'uso delle release LTS per i loro dispositivi, consentendo a questi ultimi di ricevere bug e aggiornamenti della sicurezza direttamente dalla community dei kernel Linux.
Sicurezza
Durante le release del kernel, la community dei kernel Linux non dichiara quasi mai modifiche specifiche come correzioni di sicurezza. Ciò è dovuto al problema di base la difficoltà nel determinare se una correzione di bug è o meno una correzione di sicurezza della creazione. Inoltre, molte correzioni di bug sono ritenute essere solo relative alla sicurezza una volta trascorso molto tempo, quindi la community del kernel consiglia vivamente con tutte le correzioni di bug rilasciate.
Quando i problemi di sicurezza vengono segnalati alla community del kernel, vengono risolti come il prima possibile e sono state trasferite pubblicamente all'albero dello sviluppo release stabili. Come descritto in precedenza, le modifiche non vengono quasi mai descritte come una "correzione di sicurezza", ma assomiglia a qualsiasi altra correzione di bug per il kernel. Questo è per consentire alle parti interessate di aggiornare i propri sistemi prima che segnala il problema.
Per dettagli su come segnalare bug di sicurezza alla community del kernel per risolte e risolte il prima possibile, consulta I bug di sicurezza sono disponibili nella Guida per l'utente e l'amministratore del kernel Linux all'indirizzo www.kernel.org.
Poiché i bug di sicurezza non vengono annunciati al pubblico dal team del kernel, CVE i numeri per problemi relativi ai kernel Linux vengono solitamente rilasciati con settimane, mesi e a volte anni dopo la fusione della correzione nello stabile e nello sviluppo rami.
Proteggere un sistema
Quando esegui il deployment di un dispositivo che utilizza Linux, consigliamo vivamente a tutti Gli aggiornamenti del kernel LTS vengono presi dal produttore ed eseguito il push agli utenti dopo i test appropriati dimostra che l'aggiornamento funziona bene. Questo approccio offre diversi vantaggi:
- Le release sono state esaminate dagli sviluppatori del kernel nel complesso, non in le singole parti.
- È difficile determinare quali patch risolvono il problema di "sicurezza" problemi e quelli che non lo fanno. Quasi tutte le release LTS contengono almeno una versione correzione di sicurezza e molti sono ancora "sconosciuti".
- Se il test mostra un problema, la community di sviluppatori del kernel reagisce rapidamente per risolvere il problema.
- I tentativi di filtrare solo le modifiche che esegui generano risultati in un kernel impossibile unire correttamente le versioni future dell'upstream.