Was ist ein fehlerhafter Kernel unter Linux?

Unter bestimmten Umständen kann der Linux-Kernel beschädigt werden . Wenn Sie beispielsweise einen proprietären Videotreiber in den Kernel laden, wird der Kernel beschädigt. Dieser Zustand kann in Systemprotokollen, Kernelfehlermeldungen (oops und panics) und über Tools wie lsmodund bis zum Neustart des Systems angezeigt werden.

Was bedeutet das? Beeinträchtigt es meine Fähigkeit, das System zu nutzen, und wie könnte es sich auf meine Support-Optionen auswirken?

Wenn der Kernel beschädigt ist, bedeutet dies, dass er sich in einem Zustand befindet, der nicht von der Community unterstützt wird . Die meisten Kernel-Entwickler ignorieren Fehlerberichte, die befallene Kernel betreffen, und Community-Mitglieder bitten Sie möglicherweise, den Befallszustand zu korrigieren, bevor sie Probleme im Zusammenhang mit dem Kernel diagnostizieren können. Darüber hinaus sind einige Debugging-Funktionen und API-Aufrufe möglicherweise deaktiviert, wenn der Kernel beschädigt ist.

In den meisten Fällen mit proprietären Treibern können Sie den Verschmutzungszustand ignorieren. Einige Szenarien, die dazu führen, dass der Kernel verschmutzt wird, können jedoch auf schwerwiegende Systemprobleme hinweisen.

Die Funktion soll Bedingungen identifizieren, die die ordnungsgemäße Behebung 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 getan hat. Wenn im Kernel zuvor ein Fehler aufgetreten ist oder ein schwerwiegender Hardwarefehler aufgetreten ist, sind die vom Kernel generierten Debuginformationen möglicherweise nicht zuverlässig.

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

• 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- Treibern, die Teil des Kernel-Quellcodes sind, jedoch nicht vollständig getestet wurden
• Die Verwendung von Out-of-Tree- Modulen, die nicht im Linux-Kernel-Quellcode enthalten sind
• Erzwungenes Laden oder Entladen eines Kernelmoduls (z. B. erzwungenes Einfügen eines Moduls, das nicht für die aktuelle Version des Kernels erstellt wurde)
• Verwendung eines SMP-Kernels (Multiprozessor-Kernel) auf bestimmten nicht unterstützten Einprozessor-CPUs, hauptsächlich älteren AMD Athlon-Prozessoren
• Aufschalten des ACPI DSDT, benötigt manchmal für Power-Management - Fehler zu korrigieren (siehe hier für weitere Details)
• Bestimmte kritische Fehlerbedingungen, z. B. Ausnahmen bei der Maschinenüberprüfung und Fehler beim Kernel
• Bestimmte schwerwiegende Fehler in der Systemfirmware (BIOS, UEFI), die der Kernel umgehen muss

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

Weitere Informationen finden Sie in der Kerneldokumentation . Die dort aufgelisteten Taint-Flags sind (mit _ als Ersatz für 'leer')

• G | P : G wenn alle geladenen Module eine GPL oder eine kompatible Lizenz haben, andernfalls wurde ein proprietäres Modul geladen. Module ohne MODULE_LICENSE oder mit einer MODULE_LICENSE, die von insmod nicht als GPL-kompatibel erkannt werden, gelten als proprietär.
• F | _ : Wenn ein Modul mit "insmod -f" geladen wurde, andernfalls, wenn alle Module normal geladen wurden.
• S | _ : Wenn das Hoppla auf einem SMP-Kernel aufgetreten ist, der auf Hardware ausgeführt wird, 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 zwangsweise entladen wurde rmmod -f, andernfalls, wenn alle Module normal entladen wurden.
• M | _ : Wenn ein Prozessor eine Maschinenprüfungsausnahme gemeldet hat , sind ansonsten keine Maschinenprüfungsausnahmen aufgetreten.
• B | _ : Wenn eine Seitenfreigabefunktion einen ungültigen Seitenverweis oder unerwartete Seitenflags gefunden hat.
• U | _ : Wenn ein Benutzer oder eine Benutzeranwendung ausdrücklich das Setzen des Tainted-Flags angefordert hat.
• D | _ : wenn der Kernel kürzlich gestorben ist, dh es gab ein OOPS oder einen BUG.
• A | _ : wenn die ACPI-Tabelle überschrieben wurde.
• W | _ : Wenn der Kernel zuvor eine Warnung ausgegeben hat (Einige Warnungen können jedoch spezifischere Taint-Flags setzen.)
• 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 erstelltes ("out-of-tree") Modul geladen wurde.
• E | _ : Wenn ein nicht signiertes Modul in eine Kernel-unterstützende Modulsignatur geladen wurde.
• L | _ : Wenn auf dem System zuvor eine Soft-Lockup aufgetreten ist.
• K | _ : wenn der Kernel gepatcht wurde.