Sous certaines conditions, le noyau Linux peut devenir souillé . Par exemple, le chargement d'un pilote vidéo propriétaire dans le noyau entache le noyau. Cette condition peut être visible dans les journaux système, les messages d'erreur du noyau (oops et paniques) et via des outils tels que lsmod , et reste jusqu'à ce que le système soit redémarré.
Qu'est-ce que ça veut dire? Cela affecte-t-il ma capacité à utiliser le système et comment cela pourrait-il affecter mes options d'assistance ?
Réponse acceptée :
Lorsque le noyau est contaminé, cela signifie qu'il est dans un état qui n'est pas pris en charge par la communauté . La plupart des développeurs de noyau ignoreront les rapports de bogue impliquant des noyaux corrompus, et les membres de la communauté peuvent vous demander de corriger la condition de corruption avant de pouvoir diagnostiquer les problèmes liés au noyau. De plus, certaines fonctionnalités de débogage et appels d'API peuvent être désactivés lorsque le noyau est entaché.
Dans la plupart des cas impliquant des pilotes propriétaires, vous pouvez ignorer en toute sécurité la condition d'altération , mais certains scénarios entraînant une corruption du noyau peuvent indiquer de graves problèmes système.
La fonctionnalité est destinée à identifier les conditions qui peuvent rendre difficile le dépannage correct d'un problème de noyau. Par exemple, le chargement d'un module propriétaire peut rendre la sortie de débogage du noyau peu fiable car les développeurs du noyau n'ont pas accès au code source du module et ne peuvent donc pas déterminer ce que le module a pu faire au noyau. De même, si le noyau a déjà rencontré une condition d'erreur ou si une erreur matérielle grave s'est produite, les informations de débogage générées par le noyau peuvent ne pas être fiables.
Le noyau peut être corrompu pour plusieurs raisons , y compris (mais sans s'y limiter) les éléments suivants :
- L'utilisation d'un module de noyau propriétaire (ou non compatible GPL) :il s'agit de la cause la plus fréquente de noyaux corrompus et résulte généralement du chargement de pilotes vidéo NVIDIA ou AMD propriétaires
- L'utilisation de la mise en scène pilotes, qui font partie du code source du noyau mais ne sont pas entièrement testés
- L'utilisation de hors arbre modules qui ne sont pas inclus dans le code source du noyau Linux
- Chargement ou déchargement forcé d'un module du noyau (comme l'insertion forcée d'un module non construit pour la version actuelle du noyau)
- L'utilisation d'un noyau SMP (multiprocesseur) sur certains processeurs monoprocesseurs non pris en charge, principalement les anciens processeurs AMD Athlon
- Remplacement de l'ACPI DSDT, parfois nécessaire pour corriger les bogues de gestion de l'alimentation (voir ici pour plus de détails)
- Certaines conditions d'erreur critiques, telles que les exceptions de vérification de la machine et les oops du noyau
- Certains bugs sérieux dans le firmware du système (BIOS, UEFI) que le noyau doit contourner
Chacune de ces conditions est représentée par un drapeau particulier dans le noyau. Certains fournisseurs Linux, tels que SUSE, ajoutent des indicateurs de rejet supplémentaires pour indiquer des conditions telles que le chargement d'un module qui n'est pas pris en charge par le fournisseur.
Plus d'informations sont disponibles dans la documentation du noyau. Les drapeaux de souillure répertoriés ici sont (avec _ un remplaçant pour "vide")
- G|P :G si tous les modules chargés ont une licence GPL ou compatible, sinon un module propriétaire a été chargé. Les modules sans MODULE_LICENSE ou avec un MODULE_LICENSE qui n'est pas reconnu par insmod comme compatible GPL sont supposés être propriétaires.
- F|_ :si un module a été chargé de force par "insmod -f", sinon si tous les modules ont été chargés normalement.
- S|_ :si le problème s'est produit sur un noyau SMP exécuté sur du matériel qui n'a pas été certifié comme sûr pour exécuter un multiprocesseur. Actuellement, cela ne se produit que sur divers Athlon qui ne sont pas compatibles SMP.
- R|_ :si un module a été déchargé de force par
rmmod -f, sinon si tous les modules ont été déchargés normalement. - M|_ :si un processeur a signalé une exception de vérification de la machine,
sinon, aucune exception de vérification de la machine ne s'est produite. - B|_ :si une fonction de libération de page a trouvé une mauvaise référence de page ou des drapeaux de page inattendus.
- U|_ :si un utilisateur ou une application utilisateur a spécifiquement demandé que l'indicateur Tainted soit défini.
- D|_ :si le noyau est mort récemment, c'est-à-dire qu'il y a eu un OOPS ou un BUG.
- A|_ :si la table ACPI a été remplacée.
- W|_ :si un avertissement a déjà été émis par le noyau (bien que certains avertissements puissent définir des indicateurs de teinte plus spécifiques.)
- C|_ :si un pilote intermédiaire a été chargé.
- Je|_ :si le noyau travaille autour d'un bogue sévère dans le firmware de la plate-forme (BIOS ou similaire).
- O|_ :si un module construit en externe ("out-of-tree") a été chargé.
- E|_ :si un module non signé a été chargé dans un noyau prenant en charge la signature de module.
- L|_ :si un blocage logiciel s'est déjà produit sur le système.
- K|_ :si le noyau a été patché en direct.