Le modèle de version stable du kernel Linux a vu le jour en 2005, lorsqu'il a été déterminé que le modèle de développement du kernel existant (une nouvelle version tous les deux à trois mois) ne répondait pas aux besoins de la plupart des utilisateurs. Les utilisateurs souhaitaient que des corrections de bugs soient apportées pendant ces deux à trois mois, et les distributions Linux ont eu du mal à mettre à jour les noyaux sans les commentaires de la communauté du noyau. En règle générale, les tentatives de sécurisation des noyaux individuels et de mise à jour des dernières corrections de bugs ont représenté un effort important et déroutant de la part de nombreux individus.
Les versions stables du noyau sont basées directement sur les versions de Linus Torvalds et sont publiées environ une fois par semaine, en fonction de divers facteurs externes (saison, correctifs disponibles, charge de travail du mainteneur, etc.). La numérotation des versions stables commence par le numéro de la version du kernel, et un numéro supplémentaire est ajouté à la fin. Par exemple, Linus publie le noyau 4.4, puis les versions stables du noyau basées sur ce noyau sont numérotées 4.4.1, 4.4.2, 4.4.3, etc. Cette séquence est généralement raccourcie par le nombre 4.4.y lorsqu'elle fait référence à un arbre de versions de kernel stable. Chaque arbre de version du kernel stable est géré par un seul développeur de kernel, qui est chargé de sélectionner les correctifs nécessaires pour la version et de gérer le processus d'examen/de publication.
Les noyaux stables sont maintenus pendant toute la durée du cycle de développement en cours. Une fois que Linus a publié un nouveau kernel, l'arborescence de versions du kernel stable précédent est arrêtée et les utilisateurs doivent passer au kernel plus récent.
Kernels stables à long terme
Après un an de ce nouveau processus de version stable, il a été déterminé que de nombreux utilisateurs de Linux souhaitaient que le noyau soit pris en charge pendant plus de quelques mois. En réponse, la version du noyau avec prise en charge à long terme (LTS) a été créée, avec le premier noyau LTS (2.6.16) publié en 2006. Depuis, un nouveau kernel LTS est sélectionné une fois par an, et la communauté du kernel le maintient pendant au moins deux ans.
Au moment de la rédaction de ce document, les versions de kernel LTS sont les versions 4.4.y, 4.9.y, 4.14.y, 4.19.y, 5.4.y et 5.10.y. Un nouveau kernel est publié chaque semaine. En raison des besoins de certains utilisateurs et distributions, quelques anciens noyaux supplémentaires sont gérés par les développeurs de noyau à un cycle de publication plus lent. Vous trouverez des informations sur tous les noyaux stables à long terme, les personnes qui en sont responsables et la durée de leur maintenance sur la page kernel.org releases.
Les versions du kernel LTS acceptent en moyenne six à huit correctifs par jour, tandis que les versions du kernel stable normales contiennent 10 à 15 correctifs par jour. Le nombre de correctifs fluctue d'une version à l'autre en fonction de l'heure actuelle de la version du kernel de développement correspondante et d'autres variables externes. Plus un noyau LTS est ancien, moins de correctifs lui sont applicables, car de nombreux correctifs récents ne sont pas pertinents pour les noyaux plus anciens. Cependant, plus un noyau est ancien, plus il est difficile de rétroporter les modifications qui doivent être appliquées, en raison des modifications apportées au codebase. Par conséquent, même si le nombre de correctifs appliqués est inférieur, l'effort impliqué dans la maintenance d'un noyau LTS est plus important que celui de la maintenance du noyau stable normal.
Règles de correctifs de noyau stables
Les règles concernant ce qui peut être ajouté à une version de kernel stable sont restées presque identiques depuis leur introduction et sont résumées ci-dessous:
- doivent être manifestement correctes et testées ;
- Ne doit pas dépasser 100 lignes.
- Ne doit corriger qu'un seul problème.
- Vous devez corriger un problème signalé.
- Il peut s'agir d'un nouvel ID d'appareil ou d'une particularité pour le matériel, mais il ne doit pas ajouter de nouvelle fonctionnalité majeure.
- Doit déjà être fusionné dans l'arborescence de Linus Torvalds.
La dernière règle, "Doit déjà être fusionnée dans l'arborescence de Linus Torvalds", empêche la communauté du kernel de perdre des correctifs. La communauté ne souhaite jamais qu'un correctif soit intégré à une version de kernel stable qui ne figure pas déjà dans l'arborescence de Linus Torvalds, afin que toute personne effectuant une mise à niveau ne constate jamais de régression. Cela évite de nombreux problèmes que d'autres projets qui gèrent une branche stable et de développement peuvent rencontrer.
Mises à jour du noyau
La communauté du kernel Linux a promis à ses utilisateurs qu'aucune mise à niveau ne viendrait jamais perturber le fonctionnement d'une version précédente. Cette promesse est toujours d'actualité. Les régressions se produisent, mais ce sont les bugs de priorité la plus élevée. Ils sont soit rapidement corrigés, soit la modification à l'origine de la régression est rapidement annulée dans l'arborescence du noyau Linux.
Cette promesse est valable à la fois pour les mises à jour incrémentielles du kernel stable et pour les mises à jour majeures plus importantes qui ont lieu tous les trois mois. Toutefois, la communauté du kernel ne peut faire cette promesse que pour le code fusionné dans l'arborescence du kernel Linux. Tout code fusionné dans le noyau d'un appareil qui ne figure pas dans les versions kernel.org est inconnu, et les interactions avec celui-ci ne peuvent jamais être planifiées ni même envisagées.
Les appareils basés sur Linux qui disposent de grands ensembles de correctifs peuvent rencontrer des problèmes majeurs lors de la mise à niveau vers des noyaux plus récents, en raison du grand nombre de modifications entre chaque version (10 000 à 14 000 modifications par version). Les ensembles de correctifs SoC sont particulièrement connus pour rencontrer des problèmes de mise à jour vers des noyaux plus récents en raison de leur grande taille et de la modification importante du code du noyau spécifique à l'architecture, et parfois au noyau. Par conséquent, la plupart des fournisseurs de SoC commencent à standardiser l'utilisation des versions LTS pour leurs appareils, ce qui leur permet de recevoir des mises à jour de sécurité et de bugs directement de la communauté du kernel Linux.
Sécurité
Lors des versions du kernel, la communauté du kernel Linux ne déclare presque jamais des modifications spécifiques comme des correctifs de sécurité. Cela est dû au problème de base de la difficulté à déterminer si une correction de bug est une correction de sécurité ou non au moment de la création. De plus, de nombreux correctifs ne sont considérés comme liés à la sécurité qu'après un long moment. La communauté du noyau recommande donc vivement de toujours appliquer tous les correctifs publiés.
Lorsque des problèmes de sécurité sont signalés à la communauté du kernel, ils sont corrigés dès que possible et publiés publiquement dans l'arborescence de développement et les versions stables. Comme décrit ci-dessus, les modifications ne sont presque jamais décrites comme une "correction de sécurité", mais ressemblent plutôt à n'importe quelle autre correction de bug pour le noyau. Cela permet aux personnes concernées de mettre à jour leurs systèmes avant que le signaleur du problème ne l'annonce.
Pour savoir comment signaler des bugs de sécurité à la communauté du kernel afin qu'ils soient résolus et corrigés dès que possible, consultez les bugs de sécurité dans le guide de l'utilisateur et de l'administrateur du kernel Linux sur www.kernel.org.
Étant donné que l'équipe du noyau ne publie pas les bugs de sécurité auprès du public, les numéros CVE pour les problèmes liés au noyau Linux sont généralement publiés des semaines, des mois et parfois des années après la fusion du correctif dans les branches stables et de développement.
Maintenir un système sécurisé
Lorsque vous déployez un appareil qui utilise Linux, nous vous recommandons vivement que toutes les mises à jour du noyau LTS soient prises en charge par le fabricant et diffusées auprès de ses utilisateurs après que des tests appropriés ont montré que la mise à jour fonctionne correctement. Ce fonctionnement offre plusieurs avantages :
- Les versions ont été examinées par les développeurs du noyau dans leur ensemble, et non par parties.
- Il est difficile de déterminer quels correctifs corrigent les problèmes de "sécurité" et lesquels ne le font pas. Presque toutes les versions LTS contiennent au moins un correctif de sécurité connu et de nombreux correctifs "inconnus".
- Si les tests révèlent un problème, la communauté des développeurs de noyau réagit rapidement pour le résoudre.
- Les tentatives de filtrage des modifications que vous exécutez génèrent un arbre de noyau impossible à fusionner correctement avec les futures versions en amont.