Linux – Ein verdorbener Kernel in Linux?

Unter bestimmten Bedingungen kann der Linux-Kernel verschmutzt werden . Wenn Sie beispielsweise einen proprietären Videotreiber in den Kernel laden, wird der Kernel verdorben. Dieser Zustand kann in Systemprotokollen, Kernel-Fehlermeldungen (Oops und Panik) und durch Tools wie lsmod sichtbar sein , und bleibt bestehen, bis das System neu gestartet wird.

Was bedeutet das? Beeinträchtigt es meine Fähigkeit, das System zu verwenden, und wie könnte es meine Support-Optionen beeinflussen?

Akzeptierte Antwort:

Wenn der Kernel verfälscht ist, bedeutet dies, dass er sich in einem Zustand befindet, der von der Community nicht unterstützt wird . Die meisten Kernel-Entwickler ignorieren Fehlerberichte mit verdorbenen Kerneln, und Community-Mitglieder können Sie bitten, die Verunreinigungsbedingung zu korrigieren, bevor sie mit der Diagnose von Problemen im Zusammenhang mit dem Kernel fortfahren können. Darüber hinaus können einige Debugging-Funktionen und API-Aufrufe deaktiviert werden, wenn der Kernel verdorben ist.

In den meisten Fällen mit proprietären Treibern können Sie die Taint-Bedingung getrost ignorieren , aber einige Szenarien, die dazu führen, dass der Kernel beschädigt wird, können auf ernsthafte Systemprobleme hindeuten.

Die Funktion soll Bedingungen identifizieren, die die ordnungsgemäße Fehlerbehebung eines Kernelproblems erschweren können. Beispielsweise kann das Laden eines proprietären Moduls die Kernel-Debug-Ausgabe unzuverlässig machen, da Kernel-Entwickler keinen Zugriff auf den Quellcode des Moduls haben und daher nicht feststellen können, was das Modul möglicherweise mit dem Kernel gemacht hat. Wenn der Kernel zuvor einen Fehlerzustand erlebt hat oder wenn ein schwerwiegender Hardwarefehler aufgetreten ist, sind die vom Kernel generierten Debug-Informationen möglicherweise nicht zuverlässig.

Der Kernel kann aus verschiedenen Gründen beschädigt werden , einschließlich (aber nicht beschränkt auf) Folgendes:

• Die Verwendung eines proprietären (oder nicht GPL-kompatiblen) Kernelmoduls – dies ist die häufigste Ursache für fehlerhafte Kernel und resultiert normalerweise aus dem Laden proprietärer NVIDIA- oder AMD-Grafiktreiber
• Die Verwendung von Staging Treiber, die Teil des Kernel-Quellcodes sind, aber nicht vollständig getestet wurden
• Die Verwendung von out-of-tree Module, die nicht im Linux-Kernel-Quellcode enthalten sind
• Erzwungenes Laden oder Entladen eines Kernelmoduls (z. B. das erzwungene Einfügen eines Moduls, das nicht für die aktuelle Version des Kernels erstellt wurde)
• Die Verwendung eines SMP-Kernels (Multiprozessor) auf bestimmten nicht unterstützten Einprozessor-CPUs, hauptsächlich älteren AMD Athlon-Prozessoren
• Überschreiben der ACPI-DSDT, manchmal erforderlich, um Energieverwaltungsfehler zu korrigieren (siehe hier für Details)
• Bestimmte kritische Fehlerzustände, wie z. B. Maschinenüberprüfungsausnahmen und Kernel-Oopses
• Bestimmte schwerwiegende Fehler in der Systemfirmware (BIOS, UEFI), die der Kernel umgehen muss

Jede dieser Bedingungen wird durch ein bestimmtes Flag im Kernel repräsentiert. Einige Linux-Anbieter, wie z. B. SUSE, fügen zusätzliche Taint-Flags hinzu um Bedingungen wie das Laden eines Moduls anzuzeigen, das vom Anbieter nicht unterstützt wird.

Weitere Informationen finden Sie in der Kernel-Dokumentation. Die dort aufgeführten Taint-Flags sind (mit _ als Platzhalter für „leer“)

• G|P :G wenn alle geladenen Module eine GPL oder kompatible Lizenz haben, ansonsten wurde ein proprietäres Modul geladen. Module ohne MODULE_LICENSE oder mit einer MODULE_LICENSE, die von insmod nicht als GPL-kompatibel erkannt wird, gelten als proprietär.
• F|_ :Wenn ein Modul durch „insmod -f“ zwangsweise geladen wurde, andernfalls, wenn alle Module normal geladen wurden.
• S|_ :Wenn die Ups auf einem SMP-Kernel auftraten, der auf Hardware ausgeführt wurde, die nicht als sicher für die Ausführung von Multiprozessoren zertifiziert wurde. Derzeit tritt dies nur bei verschiedenen Athlons auf, die nicht SMP-fähig sind.
• R|_ :wenn ein Modul durch rmmod -f zwangsweise entladen wurde , sonst wenn alle Module normal entladen wurden.
• M|_ :Wenn ein Prozessor eine Maschinenprüfungs-Ausnahme gemeldet hat,
  andernfalls sind keine Maschinenprüfungs-Ausnahmen aufgetreten.
• B|_ :wenn eine Seitenfreigabefunktion eine fehlerhafte Seitenreferenz oder einige unerwartete Seitenflags gefunden hat.
• U|_ :wenn ein Benutzer oder eine Benutzeranwendung ausdrücklich angefordert hat, dass das Tainted-Flag gesetzt wird.
• D|_ :wenn der Kernel vor kurzem gestorben ist, d.h. es gab ein OOPS oder BUG.
• A|_ :wenn die ACPI-Tabelle überschrieben wurde.
• W|_ :wenn zuvor eine Warnung vom Kernel ausgegeben wurde (obwohl einige Warnungen spezifischere Taint-Flags setzen können.)
• C|_ :wenn ein Staging-Treiber geladen wurde.
• I|_ :wenn der Kernel einen schwerwiegenden Fehler in der Plattform-Firmware (BIOS oder ähnliches) umgeht.
• O|_ :wenn ein extern gebautes ("out-of-tree") Modul geladen wurde.
• E|_ :wenn ein unsigniertes Modul in eine Kernel-unterstützende Modulsignatur geladen wurde.
• L|_ :wenn zuvor ein Soft-Lockup auf dem System aufgetreten ist.
• K|_ :ob der Kernel live gepatcht wurde.

Siehe auch:Linux – Wie kann ich einen Befehl verzögert im Hintergrund ausführen?