linux-4.1.15_CVE-2022-3564

INSTALLATION DER KERNELQUELLEN:

• Wenn Sie die vollständigen Quellen installieren, legen Sie das Kernel-Tarball in ein Verzeichnis, für das Sie Schreibrechte haben (z. B. Ihr Home-Verzeichnis) und entpacken Sie es:

  xz -cd linux-4.X.tar.xz | tar xvf -

  Ersetzen Sie "X" durch die Versionsnummer des aktuellen Kernels.

  Verwenden Sie NICHT den Bereich /usr/src/linux! In diesem Bereich befindet sich ein (normalerweise unvollständiger) Satz von Kernel-Headern, die von den Library-Header-Dateien verwendet werden. Sie sollten mit der Bibliothek übereinstimmen und nicht von dem jeweiligen Kernel-du-jour durcheinandergebracht werden.

• Sie können auch zwischen 4.x-Versionen durch Patchen aktualisieren. Patches werden im xz-Format verteilt. Um durch Patchen zu installieren, besorgen Sie sich alle neueren Patch-Dateien, wechseln Sie in das Hauptverzeichnis der Kernelquellen (linux-4.X) und führen Sie aus:

  xz -cd ../patch-4.x.xz | patch -p1

  Ersetzen Sie "x" für alle Versionen größer als die Version "X" Ihres aktuellen Quellbaums, der Reihe nach, und alles sollte funktionieren. Möglicherweise möchten Sie die Backup-Dateien (some-file-name~ oder some-file-name.orig) entfernen und sicherstellen, dass keine fehlgeschlagenen Patches vorhanden sind (some-file-name# oder some-file-name.rej). Falls doch, haben entweder Sie oder ich einen Fehler gemacht.

  Anders als Patches für die 4.x-Kernel sind Patches für die 4.x.y-Kernel (auch bekannt als -stable-Kernel) nicht inkrementell, sondern werden direkt auf den Basis-Kernel 4.x angewendet. Wenn Ihr Basis-Kernel beispielsweise 4.0 ist und Sie den Patch 4.0.3 anwenden möchten, dürfen Sie nicht zuerst die Patches 4.0.1 und 4.0.2 anwenden. Wenn Sie Kernelversion 4.0.2 ausführen und auf 4.0.3 springen möchten, müssen Sie zuerst den Patch 4.0.2 rückgängig machen (d. h. patch -R) bevor Sie den Patch 4.0.3 anwenden. Weitere Informationen dazu finden Sie in Documentation/applying-patches.txt

  Alternativ kann das Skript patch-kernel verwendet werden, um diesen Prozess zu automatisieren. Es ermittelt die aktuelle Kernelversion und wendet alle gefundenen Patches an.

  linux/scripts/patch-kernel linux

  Das erste Argument in obigem Befehl ist der Speicherort der Kernelquellen. Patche werden aus dem aktuellen Verzeichnis angewendet, aber ein alternatives Verzeichnis kann als zweites Argument angegeben werden.

• Stellen Sie sicher, dass keine veralteten .o-Dateien und Abhängigkeiten herumliegen:

  cd linux make mrproper

  Sie sollten nun die Quellen korrekt installiert haben.

SOFTWARE-ANFORDERUNGEN

Zum Kompilieren und Ausführen der 4.x-Kernel werden aktuelle Versionen verschiedener Softwarepakete benötigt. Konsultieren Sie Documentation/Changes für die erforderlichen Mindestversionsnummern und wie Sie Updates für diese Pakete erhalten. Beachten Sie, dass die Verwendung übermäßig alter Versionen dieser Pakete indirekte Fehler verursachen kann, die sehr schwer zu finden sind. Gehen Sie also nicht davon aus, dass Sie Pakete einfach aktualisieren können, wenn während des Builds oder Betriebs offensichtliche Probleme auftreten.

BUILD-VERZEICHNIS FÜR DEN KERNEL:

Beim Kompilieren des Kernels werden alle Ausgabedateien standardmäßig zusammen mit den Kernelquellen gespeichert. Mit der Option "make O=output/dir" können Sie einen alternativen Ort für die Ausgabedateien (einschließlich .config) angeben. Beispiel:

Um den Kernel zu konfigurieren und zu bauen, verwenden Sie:

Bitte beachten: Wenn die Option 'O=output/dir' verwendet wird, muss sie für alle make-Aufrufe verwendet werden.

KERNEL KONFIGURIEREN:

Überspringen Sie diesen Schritt nicht, selbst wenn Sie nur eine Nebenversion aktualisieren. In jeder Version werden neue Konfigurationsoptionen hinzugefügt, und es treten seltsame Probleme auf, wenn die Konfigurationsdateien nicht wie erwartet eingerichtet sind. Wenn Sie Ihre vorhandene Konfiguration mit minimalem Aufwand auf eine neue Version übertragen möchten, verwenden Sie "make oldconfig", das Sie nur nach den Antworten auf neue Fragen fragt.

• Alternative Konfigurationsbefehle sind:

  "make config" Reine Textoberfläche.

  "make menuconfig" Textbasierte Farbmenüs, Radiolisten und Dialoge.

  "make nconfig" Verbesserte textbasierte Farbmenüs.

  "make xconfig" X-Windows (Qt)-basiertes Konfigurationswerkzeug.

  "make gconfig" X-Windows (Gtk)-basiertes Konfigurationswerkzeug.

  "make oldconfig" Standardmäßig alle Fragen basierend auf dem Inhalt Ihrer vorhandenen ./.config-Datei und Nachfragen zu neuen Konfigurationssymbolen.

  "make silentoldconfig" Wie oben, vermeidet jedoch das Überladen des Bildschirms mit bereits beantworteten Fragen. Aktualisiert zusätzlich die Abhängigkeiten.

  "make olddefconfig" Wie oben, setzt jedoch neue Symbole ohne Nachfrage auf ihre Standardwerte.

  "make defconfig" Erstellen einer ./.config-Datei unter Verwendung der Standardsymbolwerte entweder aus arch/$ARCH/defconfig oder arch/$ARCH/configs/${PLATFORM}_defconfig, abhängig von der Architektur.

  "make ${PLATFORM}_defconfig" Erstellen einer ./.config-Datei unter Verwendung der Standardsymbolwerte aus arch/$ARCH/configs/${PLATFORM}_defconfig. Verwenden Sie "make help", um eine Liste aller verfügbaren Plattformen Ihrer Architektur zu erhalten.

  "make allyesconfig" Erstellen einer ./.config-Datei, indem Symbolwerte so weit wie möglich auf 'y' gesetzt werden.

  "make allmodconfig" Erstellen einer ./.config-Datei, indem Symbolwerte so weit wie möglich auf 'm' gesetzt werden.

  "make allnoconfig" Erstellen einer ./.config-Datei, indem Symbolwerte so weit wie möglich auf 'n' gesetzt werden.

  "make randconfig" Erstellen einer ./.config-Datei, indem Symbolwerte auf zufällige Werte gesetzt werden.

  "make localmodconfig" Erstellen einer Konfiguration basierend auf der aktuellen Konfiguration und den geladenen Modulen (lsmod). Deaktiviert jede Moduloption, die für die geladenen Module nicht benötigt wird.

  root@kitploit:~

                      Um eine localmodconfig für einen anderen Rechner zu
                      erstellen, speichern Sie das lsmod dieses Rechners in
                      einer Datei und übergeben Sie es als LSMOD-Parameter.
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      Das obige funktioniert auch beim Cross-Kompilieren.
  

  "make localyesconfig" Ähnlich wie localmodconfig, außer dass alle Moduloptionen in eingebaute (=y) Optionen umgewandelt werden.

  Weitere Informationen zur Verwendung der Linux-Kernel-Konfigurationswerkzeuge finden Sie in Documentation/kbuild/kconfig.txt.

• HINWEISE zu "make config":

  • Unnötige Treiber machen den Kernel größer und können unter bestimmten Umständen zu Problemen führen: Die Suche nach einer nicht vorhandenen Controllerkarte kann Ihre anderen Controller verwirren.

  • Das Kompilieren des Kernels mit einem auf höher als 386 gesetzten "Processor type" führt zu einem Kernel, der NICHT auf einem 386 funktioniert. Der Kernel erkennt dies beim Booten und gibt auf.

  • Ein Kernel mit integrierter Mathematik-Emulation wird den Coprozessor verwenden, falls einer vorhanden ist: Die Mathematik-Emulation wird in diesem Fall einfach nie verwendet. Der Kernel wird etwas größer sein, aber auf verschiedenen Maschinen funktionieren, unabhängig davon, ob sie einen Mathematik-Coprozessor haben oder nicht.

  • Die "kernel hacking"-Konfigurationsdetails führen normalerweise zu einem größeren oder langsameren Kernel (oder beidem) und können den Kernel sogar instabiler machen, indem einige Routinen konfiguriert werden, die aktiv versuchen, fehlerhaften Code zu finden, um Kernelprobleme zu identifizieren (kmalloc()). Daher sollten Sie die Fragen zu "development", "experimental" oder "debugging"-Funktionen wahrscheinlich mit 'n' beantworten.

KERNEL KOMPILIEREN:

• Stellen Sie sicher, dass mindestens gcc 3.2 verfügbar ist. Weitere Informationen finden Sie in Documentation/Changes.

  Bitte beachten Sie, dass Sie mit diesem Kernel weiterhin a.out-Benutzerprogramme ausführen können.

• Führen Sie "make" aus, um ein komprimiertes Kernel-Image zu erstellen. Es ist auch möglich, "make install" auszuführen, wenn lilo installiert ist, das zu den Kernel-Makefiles passt, aber Sie sollten zuerst Ihre spezielle lilo-Konfiguration überprüfen.

  Für die eigentliche Installation müssen Sie root sein, aber keiner der normalen Build-Schritte sollte das erfordern. Nehmen Sie den Namen root nicht leichtfertig in den Mund.

• Wenn Sie Teile des Kernels als modules konfiguriert haben, müssen Sie auch "make modules_install" ausführen.

• Ausführliche Kernel-Kompilierungs-/Build-Ausgabe:

  Normalerweise läuft das Kernel-Build-System in einem relativ leisen Modus (aber nicht völlig still). Manchmal müssen Sie jedoch oder andere Kernelentwickler die Kompilierungs-, Link- oder anderen Befehle genau so sehen, wie sie ausgeführt werden. Verwenden Sie dazu den "verbose"-Build-Modus. Dies wird durch Einfügen von "V=1" in den "make"-Befehl erreicht. Z.B.:

  make V=1 all

  Um das Build-System auch den Grund für den Neubau jedes Ziels angeben zu lassen, verwenden Sie "V=2". Die Standardeinstellung ist "V=0".

• Halten Sie ein Backup-Kernel bereit, falls etwas schiefgeht. Dies gilt insbesondere für Entwicklungsversionen, da jede neue Version neuen Code enthält, der nicht debuggt wurde. Stellen Sie sicher, dass Sie auch ein Backup der zu diesem Kernel gehörenden Module haben. Wenn Sie einen neuen Kernel mit derselben Versionsnummer wie Ihr funktionierender Kernel installieren, erstellen Sie ein Backup Ihres Module-Verzeichnisses, bevor Sie "make modules_install" ausführen.

  Alternativ können Sie vor dem Kompilieren die Kernel-Konfigurationsoption "LOCALVERSION" verwenden, um einen eindeutigen Suffix an die normale Kernelversion anzuhängen. LOCALVERSION kann im Menü "General Setup" eingestellt werden.

• Um Ihren neuen Kernel zu booten, müssen Sie das Kernel-Image (z. B. .../linux/arch/i386/boot/bzImage nach der Kompilierung) an den Ort kopieren, an dem sich Ihr normaler bootfähiger Kernel befindet.

• Das Booten eines Kernels direkt von einer Diskette ohne Hilfe eines Bootloaders wie LILO wird nicht mehr unterstützt.

  Wenn Sie Linux von der Festplatte booten, verwenden Sie wahrscheinlich LILO, das das in der Datei /etc/lilo.conf angegebene Kernel-Image verwendet. Die Kernel-Image-Datei ist normalerweise /vmlinuz, /boot/vmlinuz, /bzImage oder /boot/bzImage. Um den neuen Kernel zu verwenden, speichern Sie eine Kopie des alten Images und kopieren Sie das neue Image über das alte. Dann MÜSSEN SIE LILO NEU AUSFÜHREN, um die Ladetabelle zu aktualisieren!! Wenn Sie das nicht tun, können Sie das neue Kernel-Image nicht booten.

  Die Neuinstallation von LILO erfolgt normalerweise durch Ausführen von /sbin/lilo. Sie können /etc/lilo.conf bearbeiten, um einen Eintrag für Ihr altes Kernel-Image (z. B. /vmlinux.old) hinzuzufügen, falls das neue nicht funktioniert. Weitere Informationen finden Sie in der LILO-Dokumentation.

  Nach der Neuinstallation von LILO sollte alles bereit sein. Fahren Sie das System herunter, starten Sie neu und genießen Sie es!

  Wenn Sie jemals das Standard-Root-Gerät, den Videomodus, die Ramdisk-Größe usw. im Kernel-Image ändern müssen, verwenden Sie das Programm 'rdev' (oder alternativ die LILO-Boot-Optionen, wenn angemessen). Es ist nicht nötig, den Kernel neu zu kompilieren, um diese Parameter zu ändern.

• Starten Sie mit dem neuen Kernel neu und genießen Sie es.

WENN ETWAS SCHIEFGEHT:

• Wenn Sie Probleme haben, die auf Kernel-Fehler zurückzuführen zu sein scheinen, überprüfen Sie bitte die Datei MAINTAINERS, um zu sehen, ob es eine bestimmte Person gibt, die mit dem Teil des Kernels verbunden ist, mit dem Sie Probleme haben. Wenn dort niemand aufgeführt ist, ist die zweitbeste Lösung, mir eine E-Mail zu schicken ([email protected]) und möglicherweise an eine andere relevante Mailingliste oder Newsgroup.

• Bitte teilen Sie in allen Fehlerberichten mit, welchen Kernel Sie verwenden, wie das Problem reproduziert werden kann und wie Ihr System eingerichtet ist (verwenden Sie Ihren gesunden Menschenverstand). Wenn das Problem neu ist, teilen Sie mir das mit, und wenn das Problem alt ist, versuchen Sie bitte mitzuteilen, wann Sie es zum ersten Mal bemerkt haben.

• Wenn der Fehler zu einer Meldung wie

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  oder ähnlichen Kernel-Debugging-Informationen auf Ihrem Bildschirm oder in Ihrem Systemprotokoll führt, reproduzieren Sie diese bitte exakt. Der Dump mag für Sie unverständlich sein, enthält aber Informationen, die beim Debuggen des Problems helfen können. Der Text über dem Dump ist ebenfalls wichtig: Er gibt Aufschluss darüber, warum der Kernel Code ausgegeben hat (im obigen Beispiel liegt es an einem ungültigen Kernel-Zeiger). Weitere Informationen zum Verständnis des Dumps finden Sie in Documentation/oops-tracing.txt

• Wenn Sie den Kernel mit CONFIG_KALLSYMS kompiliert haben, können Sie den Dump so senden, andernfalls müssen Sie das Programm "ksymoops" verwenden, um den Dump zu verstehen (aber das Kompilieren mit CONFIG_KALLSYMS wird normalerweise bevorzugt). Dieses Dienstprogramm kann von ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ heruntergeladen werden. Alternativ können Sie die Dump-Suche von Hand durchführen:

• Bei Debugging-Dumps wie dem obigen hilft es enorm, wenn Sie nachschlagen können, was der EIP-Wert bedeutet. Der hexadezimale Wert als solcher hilft mir oder anderen nicht sehr viel: Er hängt von Ihrer speziellen Kernel- Konfiguration ab. Was Sie tun sollten, ist, den Hexadezimalwert aus der EIP-Zeile zu nehmen (ignorieren Sie die "0010:"), und ihn in der Kernel- Namensliste nachzuschlagen, um zu sehen, welche Kernel-Funktion die fehlerhafte Adresse enthält.

  Um den Kernel-Funktionsnamen zu finden, müssen Sie die Systembinärdatei finden, die zu dem Kernel gehört, der das Symptom gezeigt hat. Dies ist die Datei 'linux/vmlinux'. Um die Namensliste zu extrahieren und mit dem EIP aus dem Kernel-Absturz abzugleichen, führen Sie Folgendes aus:

  nm vmlinux | sort | less

  Dies gibt Ihnen eine Liste von Kernel-Adressen in aufsteigender Reihenfolge, aus der es einfach ist, die Funktion zu finden, die die fehlerhafte Adresse enthält. Beachten Sie, dass die von den Kernel-Debugging-Meldungen angegebene Adresse nicht unbedingt genau mit den Funktionsadressen übereinstimmt (eigentlich ist das sehr unwahrscheinlich), daher können Sie die Liste nicht einfach 'grep' durchsuchen: Die Liste gibt Ihnen jedoch den Startpunkt jeder Kernel-Funktion. Wenn Sie also nach der Funktion suchen, deren Startadresse niedriger ist als die gesuchte, aber von einer Funktion mit höherer Adresse gefolgt wird, finden Sie die gewünschte. Tatsächlich kann es eine gute Idee sein, in Ihrem Problembericht etwas "Kontext" anzugeben, indem Sie ein paar Zeilen um die interessante herum zeigen.

  Wenn Sie aus irgendeinem Grund das Obige nicht tun können (Sie haben ein vorkompiliertes Kernel-Image oder ähnliches), hilft es, mir so viele Informationen wie möglich über Ihr System zu geben. Bitte lesen Sie das Dokument REPORTING-BUGS für Details.

• Alternativ können Sie gdb auf einem laufenden Kernel verwenden. (schreibgeschützt; d.h. Sie können keine Werte ändern oder Haltepunkte setzen.) Um dies zu tun, kompilieren Sie den Kernel zuerst mit -g; bearbeiten Sie arch/i386/Makefile entsprechend, führen Sie dann ein "make clean" aus. Sie müssen auch CONFIG_PROC_FS aktivieren (über "make config").

  Nachdem Sie mit dem neuen Kernel neu gestartet haben, führen Sie "gdb vmlinux /proc/kcore" aus. Sie können jetzt alle üblichen gdb-Befehle verwenden. Der Befehl, um den Punkt nachzuschlagen, an dem Ihr System abgestürzt ist, ist "l *0xXXXXXXXX". (Ersetzen Sie die XXXes mit dem EIP-Wert.)

  gdb auf einem nicht laufenden Kernel schlägt derzeit fehl, weil gdb (fälschlicherweise) den Startoffset ignoriert, für den der Kernel kompiliert ist.