Le modèle de version stable du noyau Linux a commencé en 2005, quand il a été déterminé que le modèle de développement du noyau existant (une nouvelle version tous les deux ou trois mois) était ne répond pas aux besoins de la plupart des utilisateurs. Les utilisateurs souhaitaient obtenir des corrections de bugs au cours de ces deux ou trois mois, et les distributions Linux avaient du mal à maintenir les noyaux à jour sans le feedback de la communauté du noyau. En général, les tentatives de maintien la sécurité des noyaux individuels et, avec les dernières corrections de bugs, un problème de nombreuses personnes différentes.
Les versions de noyau stables sont directement basées sur et sont publiées chaque semaine environ, en fonction de divers facteurs externes (période de l'année, les correctifs disponibles, la charge de travail du responsable, etc.). La numérotation des écuries le numéro de version du noyau est le numéro de la version est ajouté à la fin. Par exemple, le noyau 4.4 est publié par Linus, et alors 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 lorsque qui fait référence à une arborescence de versions stable du noyau. Chaque arborescence de versions stable du noyau est géré par un seul développeur de noyau, qui est chargé de choisir le les correctifs nécessaires à la publication et la gestion du processus de révision/de publication.
Les noyaux stables sont conservés pendant toute la durée du cycle de développement en cours. Lorsque Linus a publié un nouveau noyau, l'arborescence de versions stable précédente est arrêtés et les utilisateurs doivent passer au noyau le plus récent.
Noyaux stables à long terme
Au bout d'un an de ce nouveau processus de publication stable, différents utilisateurs de Linux voulaient qu’un noyau soit pris en charge plus longtemps qu’un simple quelques mois. En réponse, la version de noyau LTS (Long Term Support) a été créé, avec le premier noyau LTS (2.6.16) publié en 2006. Depuis, une nouvelle Le noyau LTS a été sélectionné une fois par an et la communauté du noyau affirme que pendant au moins 2 ans.
Au moment de la rédaction de ce document, les noyaux LTS sont les 4.4.y, 4.9.y, 4.14.y, versions 4.19.y, 5.4.y et 5.10.y. Un nouveau noyau est publié chaque semaine. Motif : aux besoins de certains utilisateurs et de certaines distributions, quelques noyaux plus anciens gérés par les développeurs de noyau à un cycle de publication plus lent. Informations sur tous les noyaux stables à long terme, qui en est responsable et combien de temps ils sont gérés, sont disponibles sur la page kernel.org versions.
Le noyau LTS publie en moyenne 6 à 8 correctifs acceptés par jour, alors que le versions de noyau stables contiennent 10 à 15 correctifs par jour. Le nombre de correctifs varie d'une version à l'autre, compte tenu de l'heure actuelle du développement correspondant la version du noyau et d'autres variables externes. Plus un noyau LTS est ancien, il y a moins de correctifs applicables, car de nombreuses corrections de bugs récentes ne sont pas pertinentes pour les noyaux plus anciens. Cependant, plus un noyau est ancien, plus il est difficile de rétroporter le modifications qui doivent être appliquées, en raison des changements apportés au codebase. Donc bien qu'il puisse y avoir un nombre global de correctifs appliqués plus faible, l'effort impliqués dans la maintenance d'un noyau LTS est plus important que le maintien du fonctionnement normal noyau stable.
Règles de correctif du noyau stables
Les règles concernant ce qui peut être ajouté à une version stable du noyau sont restées presque identiques depuis son introduction et sont résumés ci-dessous:
- Les tests doivent être corrects et testés.
- Ne doit pas dépasser 100 lignes.
- Une seule chose à corriger.
- Vous devez corriger un problème signalé.
- Peut être un nouvel identifiant d'appareil ou une particularité en termes de matériel, mais pas d'ajouter de nouvelles de Google Cloud.
- Doit déjà être fusionné avec l'album Linus Torvalds arborescence.
La dernière règle, "Doit déjà être fusionnée avec Linus Torvalds" arbre", empêche la communauté du noyau de perdre des correctifs. La communauté n'a jamais besoin d'une solution dans une version de noyau stable qui ne se trouve pas déjà dans arbre, donc que toute personne effectuant une mise à niveau ne devrait jamais constater de régression. Cela permet d'éviter que les autres projets disposant d'une branche stable et de développement dont vous disposez.
Mises à jour du noyau
La communauté du noyau Linux a promis à sa base d'utilisateurs qu'aucune mise à niveau de casser tout ce qui fonctionne dans une version précédente. Cela la promesse est toujours valable aujourd'hui. Des régressions ont lieu, mais ce sont les plus les bugs prioritaires et sont soit rapidement corrigés, soit en cas de modification la régression est rapidement annulée à partir de l'arborescence du noyau Linux.
Cette promesse est valable pour les mises à jour incrémentielles du noyau stables, ainsi que les mises à jour majeures plus importantes qui ont lieu tous les trois mois. Toutefois, la communauté du noyau ne peut faire cette promesse que pour le code qui est fusionné dans arborescence du noyau Linux. Tout code fusionné avec le noyau d'un appareil, mais pas dans les versions de kernel.org sont inconnues et des interactions avec celui-ci ne peuvent jamais être planifiées, ni même envisagées.
Les appareils basés sur Linux avec de grands ensembles de correctifs peuvent présenter des problèmes majeurs lorsqu’ils la mise à jour vers des noyaux plus récents, en raison du grand nombre de modifications entre chaque (10 à 14 000 modifications par version). Les correctifs SoC sont particulièrement connus de rencontrer des problèmes lors de la mise à jour vers des noyaux plus récents en raison de leur grande taille et de modification du code du noyau spécifique à l'architecture, voire du code principal. En tant que Résultat, 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 signalement de bugs. directement de la communauté du noyau Linux.
Sécurité
Lors des versions du noyau, la communauté du noyau Linux ne déclare presque jamais des modifications spécifiques comme des correctifs de sécurité. Cela est dû au problème fondamental la difficulté à déterminer si une correction de bug est un correctif de sécurité ou non à ce moment-là de création. De plus, de nombreuses corrections de bugs sont identifiées uniquement comme étant liées à la sécurité. après un certain temps, la communauté du noyau recommande vivement de toujours en prenant toutes les corrections de bogues publiées.
Lorsque des problèmes de sécurité sont signalés à la communauté du noyau, ils sont résolus en dans les plus brefs délais, puis de les transférer publiquement dans l'arborescence de développement. versions stables. Comme décrit ci-dessus, les changements ne sont presque jamais décrits comme un « correctif de sécurité », mais plutôt ressembler à n'importe quel autre correctif de bug pour le noyau. C'est pour permettre aux parties concernées de mettre à jour leurs systèmes avant que l'auteur du problème l'annonce.
Pour plus de détails sur le signalement de bugs de sécurité à la communauté du noyau afin d’obtenir les résoudre dans les plus brefs délais, reportez-vous Bugs de sécurité dans le guide de l'utilisateur et de l'administrateur du noyau Linux disponible à l'adresse www.kernel.org.
Les bogues de sécurité ne sont pas annoncés publiquement par l'équipe du noyau, les CVE les chiffres relatifs aux problèmes liés au noyau Linux sont généralement publiés des semaines, des mois et parfois des années après que le correctif a été fusionné avec la version stable et de développement branches.
Maintenir un système sécurisé
Lors du déploiement d'un appareil fonctionnant sous Linux, nous vous recommandons vivement Les mises à jour LTS du noyau sont effectuées par le fabricant et transmises aux utilisateurs. après les tests appropriés, la mise à jour fonctionne bien. Ce fonctionnement offre plusieurs avantages :
- Les versions ont été examinées par les développeurs du noyau dans leur ensemble, et non dans des parties individuelles.
- Il est difficile de déterminer quels correctifs résolvent la "sécurité" problèmes et ceux qui ne le font pas. Presque toutes les versions LTS contiennent au moins une version connue un correctif de sécurité, et beaucoup d’autres encore « inconnus ».
- Si les tests révèlent un problème, la communauté des développeurs du noyau réagit rapidement pour résoudre le problème.
- Les tentatives de filtrer uniquement les modifications que vous exécutez ont pour effet de générer un noyau qu'il est impossible de fusionner correctement avec les futures versions en amont.