„printk() is the king of all debuggers, […].” (LWN)

• Unterstützt verschiedene Ziele (targets), wie z. B. i386, amd64, …

• Erweiterbar um weitere Ziele mittels GDB-Stub

  (Ziel muss nur das GDB-Protokoll implementieren)

Können wir den GNU Debugger einfach für einen Betriebssystemkern (hier: Linux) nutzen?

• Lässt sich „einfach” über einen GDB bedienen

• Benötigt zwei Computer:

  Device under Test (DUT) und Entwicklungsmaschine

• Implementiert GDB-Stub über serielle Schnittstelle
• Kleine Schwester ist kdb über Tastatur am DUT
• Kennt auch Threads (= alle im System laufende Threads/Prozesse)
• Aber eine beliebige Unterbrechung mittels strg+c ist nicht möglich

• Aus dem untersuchten System die Kontrolle an den GDB übergeben

  echo g > /proc/sysrq-trigger

• Kernparameter kgdbwait

  • Unterbricht Startvorgang des Kerns
  • Übergibt Kontrolle an GDB
  • Möglichkeit, um u. a. Breakpoints zu setzen

• Verweilt nicht zu lange im GDB, bevor Ihr c drückt. Ansonsten beschwert sich der Linux-Kern

  [ 116.011870][ C0] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 50930.300 msecs

Und nu?

• Qemu implementiert GDB-Stub
• GDB sitzt daher in der Hardware → erinnert an ext. Debugger
• Jetzt sind beliebige Unterbrechungen (strg+c) möglich

• Kennt keine Threads im eigentlichen Sinne → dargestellte Threads entsprechen emulierten CPU-Kernen
• Funktioniert auch, wenn das untersuchte System steht(!)

(Geht bei uns auch mit dem Parameter -g XX/vmlinux für das Skript boot.sh)

• dtrace wurde von Sun Microsystems für Solaris entwickelt [2]
• Erlaubt die dynamische Instrumentierung von BS-Kern und Nutzeranwendungen
• Kern selbst wird nicht instrumentiert
• Daten und Anknüpfungspunkte (probe points) werden zur Laufzeit durch sog. Provider geladen
• Prädikate beschreiben Auslösebedingung, siehe Zeile 2

syscall::write:entry
/execname == "sshd" && arg0 == 5/
{
        @[ustack()] = quantize(arg2);
}

• Zwei Typen
  • kprobe: Kann an quasi jeder Assemblerinstruktion wirken
  • kretprobe: Kann bei der Rückkehr einer Funktion wirken
• Prinzip
  1. Kopiere zu untersuchende Instruktion
  2. Ersetze zu untersuchende Instruktion mit int3 (auf x86)
• Bei Auslösen der Trap (int3)
  1. Führe pre-Handler aus
  2. Führe ersetzte Instruktion aus
  3. Führe post-Handler aus

• Optimierungen
  • Nutze jmp-Instruktion statt int3
  • Nutze ftrace-Infrastruktur bei Funktionen als Ziel
• Beispiel

static void __kprobes handler_pre(struct kprobe *p, struct pt_regs *regs,
                unsigned long flags) {
    printk("before execution\n");
}
static void __kprobes handler_post(struct kprobe *p, struct pt_regs *regs,
                unsigned long flags) {
    printk("after execution\n");
}

• Moderne Werkzeuge können …
  • Daten aggregieren,
  • Fehler abfangen,
  • Kern- und Anwendungsbereich untersuchen und
  • den Mehraufwand begrenzen.
• Weitere Details zum Vergleich SystemTap und eBPF bietet ein LWN-Artikel [3]

Wir schauen uns SystemTap an. Warum? Weil ich „nur” SystemTap kann. 😎

• zu untersuchende Stelle (Funktion, …) spezifizieren
• Lokale Variablen, Funktionsargumente oder Rückgabewert stehen zur Verfügung
• Ausführen von beliebigen Aktionen – siehe language reference

probe kernel.function("vfs_write").return {
        if (stp_pid() == pid()) next
        printf("%s (%d) wrote %d bytes, expected %d\n", execname(), pid(), $return, @entry($count))
}

• Siehe language reference Abschnitt 4.2 „Built-in probe point types”
• Siehe syscall-Tapsets
  • Wrapper für die Systemaufrufe
  • Zugriff über z. B. syscall.open
• kernel.function("foo@bar.c") → Funktion foo() in Datei bar.c
• kernel.function("*@bar.c") → jede Funktion in Datei bar.c
• kernel.statement("*@fs/namei.c:3080") → Zeile 3080 in Datei fs/namei.c

• Aggregation von Daten

global bytes
probe kernel.function("vfs_write").return {
        if (stp_pid() == pid() || $return < 0) next
        bytes <<< $return
}
probe end {
        print(@hist_linear(bytes, 0, 2048, 128))
}

Ausgabe:

value |-------------------------------------------------- count
    0 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@    572
  128 |@@@                                                 36
  256 |@@@                                                 36

• Periodisch Aufgaben erledigen

probe timer.ms(1000) {
    printf("%d\n", gettimeofday_s())
}

• guru mode gestattet zusätzliche und invasive Funktionen (Parameter -g)
• Zustand sowie das Verhalten des Kerns modifzieren (Beispiele: 1, 2)

// Beispiel 1
probe kernel.function("do_fsync").return {
    # override result code, just in case kernel sent back -EINVAL or somesuch
    try { $return = 0 } catch { }
}

• C-Code einbetten (Beispiel)

probe syscall.open %{
    int i = 1;
    printk("i ist gleich %d\n", i);
%}