# kdb & kgdb: Interaktives Debugging im Kernel-Space

TL;DR / Management Summary Während Tools wie strace oder ftrace den Kernel im laufenden Betrieb beobachten, erlauben kdb und kgdb das echte interaktive Debugging. kdb ist ein in den Kernel eingebauter Debugger für die lokale Konsole (keine Unterbrechung des Kernels nötig für einfache Abfragen, stoppt ihn aber für tiefe Analyse). kgdb ist das Remote-Gegenstück, das eine serielle Verbindung zu einem zweiten PC nutzt, auf dem gdb läuft. Dies sind die ultimativen Werkzeuge für Kernel-Entwickler und Admins, die Hardware-nahe Bugs oder Deadlocks jagen.

# 1. Einführung & Architektur

Den Kernel einfrieren.

# kdb (Kernel Debugger)

kdb ist Teil des Kernels und bietet eine Shell direkt auf der Konsole. Er wird aktiv, wenn das System crasht oder wenn der Admin eine spezielle Tastenkombination drückt.

• Vorteil: Keine zweite Hardware nötig.
• Nachteil: Kein Source-Level Debugging (nur ASM und Register).

# kgdb (Kernel GDB)

kgdb erlaubt es, den Kernel wie ein normales Programm mit gdb zu steuern.

• Vorteil: Voller Zugriff auf den C-Quellcode, Variablen und Breakpoints.
• Anforderung: Zwei Systeme (Host/Target), verbunden via Nullmodem-Kabel oder virtueller serieller Schnittstelle (VM).

# Architektur-Diagramm (Mermaid)

graph LR
    subgraph "Debugger PC (Host)"
    GDB[GDB Client]
    end

    subgraph "Target PC (Server/Kernel)"
    KERNEL[Running Linux Kernel]
    KGDB_STUB[kgdb stub]
    end

    GDB <-->|Serial / Ethernet| KGDB_STUB
    KGDB_STUB <--> KERNEL

# 2. kdb: Der lokale Ersthelfer

Diagnose ohne Umwege.

# Aktivierung

kdb muss im Kernel einkompiliert sein (CONFIG_KGDB_KDB=y).

# Debugger via SysRq triggern
echo 1 > /proc/sys/kernel/sysrq
echo g > /proc/sysrq-trigger

Die Konsole friert nun ein und zeigt den kdb> Prompt.

# Wichtige kdb Befehle

• md <addr>: Speicherinhalt an Adresse anzeigen.
• rd: CPU-Register ausgeben (RAX, RBX, RIP etc.).
• ps: Prozessliste mit Status anzeigen.
• bt: Stack-Backtrace des aktuellen Threads.
• go: Kernel-Ausführung fortsetzen.

# 3. kgdb: Profi-Debugging mit Source-Code

Die Operation am offenen Herzen.

# Setup (Target)

Der Kernel muss mit kgdboc (kgdb over console) gestartet werden. In der Boot-Line (Grub):

kgdboc=ttyS0,115200 kgdbwait

kgdbwait sorgt dafür, dass der Kernel beim Booten anhält und auf den GDB-Connect wartet.

# Verbindung (Host)

Auf Ihrem Arbeitsrechner starten Sie GDB mit dem Kernel-Binary (vmlinux), das die Symbole enthält:

gdb ./vmlinux
(gdb) target remote /dev/ttyUSB0

Nun können Sie Breakpoints setzen:

(gdb) break sys_open
(gdb) continue

# 4. Deep Dive: Deadlock Analysis

Wer hat den Lock?

Ein häufiges Szenario ist ein “Hanging System”. Mit kdb können wir prüfen, wer auf einen Mutex wartet.

# Analyse-Workflow

1. In den Debugger springen (SysRq+g).
2. summary prüfen (Welche CPUs sind aktiv?).
3. btc (Backtrace on all CPUs) ausführen.
4. Suchen nach Funktionen wie mutex_lock oder spin_lock.

# 5. Troubleshooting & “War Stories”

Wenn der Debugger den Fehler versteckt.

# Top 3 Herausforderungen

1. Symptom: Tastatur reagiert nicht im kdb.

   • Ursache: USB-Tastaturen brauchen oft spezielle Kernel-Treiber, die im kdb-Modus nicht aktiv sind.
   • Lösung: Nutzen Sie eine serielle Konsole (ttyS0) oder eine alte PS/2 Tastatur.

2. Symptom: kgdb bricht die Verbindung ab.

   • Ursache: Interrupts werden während des Debuggings nicht korrekt behandelt.
   • Lösung: Deaktivieren Sie das Power-Management (nohlt in den Boot-Optionen).

3. Symptom: Variablen werden als <optimized out> angezeigt.

   • Ursache: Kernel wurde mit -O2 kompiliert.
   • Lösung: Für tiefe Entwicklung Kernel mit CONFIG_DEBUG_INFO_REDUCED=n und ggf. weniger Optimierung bauen.

# “War Story”: Der “Impossible” Null-Pointer

Wir hatten einen Crash in einem Netzwerk-Treiber. strace und ftrace zeigten nur das Ende, aber nicht das “Warum”. Mit kgdb setzten wir einen bedingten Breakpoint (break my_func if skb == 0). Nach 4 Stunden Laufzeit hielt der Kernel an. Wir konnten live sehen, dass eine Race-Condition im IRQ-Handler den Buffer freigab, bevor die Hauptfunktion ihn verarbeitete. Ein einfacher spin_lock Patch löste das Problem.

# 6. Monitoring & Sicherheit

Debugger im Produktivsystem?

ACHTUNG: Lassen Sie kgdb/kdb niemals auf öffentlich erreichbaren Servern aktiviert. Jemand mit Zugriff auf die Konsole (oder die serielle Schnittstelle) hat totale Kontrolle über das System und kann Speicher direkt manipulieren.

# 7. Fazit & Empfehlung

kdb/kgdb sind keine Tools für den Alltag, aber lebensnotwendig für die Kernel-Forensik.

• Empfehlung: Üben Sie das Setup in einer VM (z.B. in Proxmox mit zwei virtuellen seriellen Ports).
• Alternative: Wenn Sie nur Informationen extrahieren wollen, ohne den Kernel zu stoppen, ist eBPF (Artikel 414) fast immer die bessere und sicherere Wahl.

# Anhang: Cheatsheet

# Referenzen

• Kernel.org: KGDB and KDB Documentation
• Linux Device Drivers (Chapter 4: Debugging)
• GDB Remote Serial Protocol