Linux Kernel live debugging, jak to się robi i jakie narzędzia są używane?

Podczas debugowania jądra Linuksa możemy użyć kilku narzędzi, na przykład debugerów (KDB, KGDB), dumping while crashed (LKCD), tracing toolkit (LTT, LTTV, LTTng), custom kernel instruments (dprobes, kprobes). W poniższej sekcji próbowałem podsumować większość z nich, mam nadzieję, że pomogą.

LKCD (Linux Kernel Crash Dump) narzędzie pozwala systemowi Linux na zapisanie zawartości jego pamięci w przypadku awarii. Dzienniki te mogą być dalej analizowane pod kątem przyczyny crash. Zasoby dotyczące LKCD

• http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaax/lkcd.pdf
• https://www.novell.com/coolsolutions/feature/15284.html
• https://www.novell.com/support/kb/doc.php?id=3044267

Oops gdy kernel wykryje problem, wyświetla komunikat Oops. Taki komunikat jest generowany przez polecenia printk w programie obsługi błędów (arch/*/kernel/traps.c). Dedykowany bufor pierścieniowy w jądro używane przez polecenia printk. Oops zawiera informacje takie jak procesor, na którym wystąpił UPS, zawartość rejestrów procesora, liczba UPS, opis, stos back trace i inne. Zasoby dotyczące jądra Oops

• https://www.kernel.org/doc/Documentation/oops-tracing.txt
• http://madwifi-project.org/wiki/DevDocs/KernelOops
• https://wiki.ubuntu.com/DebuggingKernelOops

Dynamiczny Sondy jest jednym z popularnych narzędzi debugowania dla Linuksa, który został opracowany przez IBM. Narzędzie to umożliwia umieszczenie "sondy" w niemal każdym miejscu w systemie, zarówno w przestrzeni użytkownika, jak i jądra. Sonda składa się z jakiegoś kodu (napisanego w wyspecjalizowanym, zorientowanym na stosy języku), który jest wykonywany, gdy kontrola uderzy w dany punkt. Zasoby dotyczące sondy dynamicznej wymienione poniżej

• http://www-01.ibm.com/support/knowledgecenter/linuxonibm/liaax/dprobesltt.pdf
• http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.107.6212&rep=rep1&type=pdf

Linux Trace Toolkit jest łatką do jądra i zestawem powiązanych narzędzi, które umożliwiają śledzenie zdarzeń w jądrze. Ślad zawiera informacje o czasie i może stworzyć w miarę kompletny obraz tego, co wydarzyło się w danym okresie czasu. Zasoby LTT, LTT Viewer i LTT Next Generation

• http://elinux.org/Linux_Trace_Toolkit
• http://www.linuxjournal.com/article/3829
• http://multivax.blogspot.com/2010/11/introduction-to-linux-tracing-toolkit.html

MEMWATCH jest narzędziem do wykrywania błędów pamięci typu open source. Działa poprzez zdefiniowanie MEMWATCH w instrukcji gcc i dodanie pliku nagłówkowego do naszego kodu. Dzięki temu możemy śledzić pamięć przecieki i uszkodzenia pamięci. Zasoby dotyczące MEMWATCH

• http://www.linuxjournal.com/article/6059

Ftrace jest dobrym frameworkiem śledzenia dla jądra Linuksa. ftrace śledzi wewnętrzne operacje jądra. To narzędzie zawarte w jądrze Linuksa w wersji 2.6.27. Dzięki różnym wtyczkom tracer, ftrace może być ukierunkowany na różne statyczne punkty tracepointy, takie jak zdarzenia planowania, przerwania, odwzorowane w pamięci wejścia / wyjścia, przejścia stanu mocy procesora i operacje związane z systemami plików i wirtualizacją. Ponadto dostępne jest dynamiczne śledzenie wywołań funkcji jądra, opcjonalnie ograniczone do podzbioru funkcji za pomocą Globów oraz z możliwością generowania wykresów wywołań i zapewnienia wykorzystania stosu. Dobry samouczek ftrace znajdziesz na https://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_rostedt.pdf

Ltrace jest narzędziem do debugowania w Linuksie, używanym do wyświetlania połączeń użytkownika aplikacja space sprawia, że biblioteki współdzielone. To narzędzie może być używane do śledzenia dowolnego dynamicznego wywołania funkcji biblioteki. Przechwytuje i rejestruje dynamiczne wywołania biblioteki, które są wywoływane przez wykonywany proces oraz sygnały, które są odbierane przez ten proces. Może również przechwytywać i drukować wywołania systemowe wykonywane przez program.

• http://www.ellexus.com/getting-started-with-ltrace-how-does-it-do-that/?doing_wp_cron=1425295977.1327838897705078125000
• http://developerblog.redhat.com/2014/07/10/ltrace-for-rhel-6-and-7/

KDB jest debugerem jądra Linuksa. KDB podąża za uproszczonym interfejsem w stylu powłoki. Możemy go używać do sprawdzania pamięci, rejestrów, list procesów, dmesg, a nawet ustawiania punktów przerwania, aby zatrzymać się w określonym miejscu. Poprzez KDB możemy ustawić punkty przerwania i wykonać jakąś podstawową kontrolę nad uruchomieniem jądra (, chociaż KDB nie jest debuggerem na poziomie źródłowym ). Kilka przydatnych zasobów dotyczących KDB

• http://www.drdobbs.com/open-source/linux-kernel-debugging/184406318
• http://elinux.org/KDB
• http://dev.man-online.org/man1/kdb/
• https://www.kernel.org/pub/linux/kernel/people/jwessel/kdb/usingKDB.html

KGDB jest przeznaczony do użycia jako debugger na poziomie źródłowym dla jądra Linuksa. Jest używany wraz z gdb do debugowania jądra Linuksa. Do korzystania z kgdb potrzebne są dwie maszyny. Jedna z tych maszyn jest maszyną rozwojową, a druga jest maszyną docelową. Jądro do debugowania działa na maszynie docelowej. Oczekuje się, że gdb może być użyte do "włamania się" do jądra w celu sprawdzenia pamięci, zmiennych i przejrzenia informacji o stosie wywołań, podobnie jak programista aplikacji używałby gdb do debugowania aplikacji. Możliwe jest umieszczanie punktów przerwania w kodzie jądra i wykonywanie pewnych ograniczonych kroków wykonawczych. Kilka przydatnych zasobów dotyczących KGDB

• http://landley.net/kdocs/Documentation/DocBook/xhtml-nochunks/kgdb.html

Według wiki, kgdb została połączona z jądrem w 2.6.26, czyli w ciągu ostatnich kilku lat. kgdbjest zdalnym debugerem , więc aktywujesz go w swoim jądrze , a następnie dołączasz do niego gdb. Mówię jakoś, ponieważ wydaje się, że jest wiele opcji-patrz Podłączanie gdb . Biorąc pod uwagę, że kgdb jest teraz w drzewie źródłowym, powiedziałbym, że w przyszłości tego chcesz używać.

Kolejnym dobrym narzędziem do debugowania "na żywo" jest kprobes / dynamic probe.

Pozwala to dynamicznie budować małe moduły, które działają po wykonaniu określonych adresów - coś w rodzaju punktu przerwania.

Dużą ich zaletą są:

1. nie wpływają one na system - tzn. gdy zostanie uderzona lokacja-po prostu wykona kod - nie zatrzyma całego jądra.
2. nie potrzebujesz dwóch różnych systemów połączonych ze sobą (target i debug) jak z kgdb

Najlepiej jest wykonywać takie czynności, jak uderzanie punktu przerwania, sprawdzanie, jakie są wartości danych, sprawdzanie, czy coś zostało zmienione/nadpisane itp. Jeśli chcesz "przejść przez KOD" - nie robi tego.

Dodatek - 2018:

Kolejną bardzo wydajną metodą jest program po prostu nazywany "perf", który zwija wiele narzędzi (jak sondy dynamiczne) i zastępuje/deprymuje inne (jak oprofile).

W szczególności polecenie perf probe może być użyte do z łatwością twórz / dodawaj dynamiczne sondy do systemu, po czym perf record może pobierać próbki systemu i raportować informacje (i wstecz), gdy sonda zostanie trafiona w celu raportowania przez perf report (lub perf script). Jeśli masz dobre symbole debugowania w jądrze, możesz wyciągnąć świetne dane z systemu bez zdejmowania jądra. Wykonaj man perf (w Google lub w systemie) aby uzyskać więcej informacji na temat tego narzędzia lub zobacz tę wspaniałą stronę na nim:

Http://www.brendangregg.com/perf.html

KGDB + QEMU krok po kroku

KGDB jest podsystemem jądra, który pozwala na krok debugowania samego jądra z hosta GDB.

Mój przykład QEMU + Buildroot jest dobrym sposobem, aby spróbować go bez prawdziwego sprzętu: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/1969cd6f8d30dace81d9848c6bacbb8bad9dacd8#kgdb

Plusy i minusy a inne metody:

• advantage vs QEMU:
  • często nie masz oprogramowania emulacja dla Twojego urządzenia, ponieważ dostawcy sprzętu nie lubią wypuszczać dokładnych modeli oprogramowania dla swoich urządzeń]}
  • prawdziwy sprzęt o wiele szybszy niż QEMU
Nie ma potrzeby używania dodatkowego sprzętu JTAG, łatwiejsza konfiguracja]}
• wady vs QEMU i JTAG: mniejsza widoczność i bardziej natrętna. KGDB polega na tym, że niektóre części jądra pracują, aby móc komunikować się z hostem. Więc np. psuje się w panice, nie można obejrzeć Boota Sekwencja.

Główne kroki to:

1. Skompiluj jądro z:

   CONFIG_DEBUG_KERNEL=y
   CONFIG_DEBUG_INFO=y
   
   CONFIG_CONSOLE_POLL=y
   CONFIG_KDB_CONTINUE_CATASTROPHIC=0
   CONFIG_KDB_DEFAULT_ENABLE=0x1
   CONFIG_KDB_KEYBOARD=y
   CONFIG_KGDB=y
   CONFIG_KGDB_KDB=y
   CONFIG_KGDB_LOW_LEVEL_TRAP=y
   CONFIG_KGDB_SERIAL_CONSOLE=y
   CONFIG_KGDB_TESTS=y
   CONFIG_KGDB_TESTS_ON_BOOT=n
   CONFIG_MAGIC_SYSRQ=y
   CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x1
   CONFIG_SERIAL_KGDB_NMI=n
   

   Większość z nich nie jest obowiązkowa, ale to właśnie przetestowałem.

2. Dodaj do komendy QEMU:

   -append 'kgdbwait kgdboc=ttyS0,115200' \
   -serial tcp::1234,server,nowait
   

3. Uruchom GDB z katalogu głównego drzewa źródłowego jądra Linuksa z:

   gdb -ex 'file vmlinux' -ex 'target remote localhost:1234'
   

4. W GDB:

   (gdb) c
   

   I but powinien się skończyć.

5. W QEMU:

   echo g > /proc/sysrq-trigger
   

   I GDB powinny przerwa.

6. Teraz skończyliśmy, możesz używać GDB jak zwykle:

   b sys_write
   c
   

Testowane w Ubuntu 14.04.

KGDB + Raspberry Pi

Dokładnie taka sama konfiguracja jak powyżej prawie działała na Raspberry Pi 2, Raspbian Jessie 2016-05-27.

Musisz tylko nauczyć się wykonywać kroki QEMU na Pi, które są łatwe Googlable:

• Dodaj opcje konfiguracyjne i przekompiluj jądro tak, jak wyjaśniono na https://www.raspberrypi.org/documentation/linux/kernel/building.md w domyślnej kompilacji jądra niestety brakowało opcji, w szczególności nie było symboli debugowania, więc potrzebna jest rekompilacja.

• Edytuj cmdline.txt partycji rozruchowej i dodaj:

  kgdbwait kgdboc=ttyAMA0,115200
  

• Połącz {[11] } z serią za pomocą:

  arm-linux-gnueabihf-gdb -ex 'file vmlinux' -ex 'target remote /dev/ttyUSB0'
  

  Jeśli nie jesteś zaznajomiony z serią, sprawdź to: https://www.youtube.com/watch?v=da5Q7xL_OTo Wszystko czego potrzebujesz to tanie adapter jak ten . Upewnij się, że możesz uzyskać powłokę przez serial, aby upewnić się, że działa przed wypróbowaniem KGDB.

• Do:

  echo g | sudo tee /proc/sysrq-trigger
  

  Z wnętrza sesji SSH, ponieważ serial jest już zajęty przez GDB.

Dzięki tej konfiguracji mogłem umieścić breakpoint w sys_write, wstrzymać wykonywanie programu, wyświetlić źródło listy i kontynuować.

Jednak czasami, gdy zrobiłem next W sys_write GDB po prostu wisiał i drukował ten Komunikat o błędzie kilka razy:

Ignoring packet error, continuing...

Więc nie jestem pewien, czy coś jest nie tak z moją konfiguracją, lub jeśli oczekuje się tego z powodu tego, co jakiś proces tła robi w bardziej złożonym obrazie Raspbian.

Powiedziano mi również, aby spróbować i wyłączyć wieloprocesorowe z opcjami rozruchu Linuksa, ale nie próbowałem jeszcze.

Właściwie żartem jest to, że Linux ma debugger w jądrze od 2.2.12, xmon, ale tylko dla architektury powerpc (w rzeczywistości był to ppc wtedy).

Nie jest to debugger na poziomie źródłowym i jest prawie całkowicie nieudokumentowany, ale nadal.

Http://lxr.linux.no/linux-old+v2. 2.12/arch/ppc/xmon / xmon. c#l119

QEMU + GDB procedura krok po kroku testowana na Ubuntu 16.10 host

Aby szybko zacząć od zera, zrobiłem minimalny w pełni zautomatyzowany przykład QEMU + Buildroot pod adresem: https://github.com/cirosantilli/linux-kernel-module-cheat główne kroki zostały omówione poniżej.

Najpierw uzyskaj główny system plików rootfs.cpio.gz. Jeśli potrzebujesz, rozważ:

• minimalny init-tylko wykonywalny obraz: https://unix.stackexchange.com/questions/122717/custom-linux-distro-that-runs-just-one-program-nothing-else/238579#238579
• interaktywny system Busybox: https://unix.stackexchange.com/questions/2692/what-is-the-smallest-possible-linux-implementation/203902#203902

Następnie na jądrze Linuksa:

git checkout v4.9
make mrproper
make x86_64_defconfig
cat <<EOF >.config-fragment
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_KERNEL=y
CONFIG_GDB_SCRIPTS=y
EOF
./scripts/kconfig/merge_config.sh .config .config-fragment
make -j"$(nproc)"
qemu-system-x86_64 -kernel arch/x86/boot/bzImage \
                   -initrd rootfs.cpio.gz -S -s

Na innym terminalu, Załóżmy, że chcesz rozpocząć debugowanie od start_kernel:

gdb \
    -ex "add-auto-load-safe-path $(pwd)" \
    -ex "file vmlinux" \
    -ex 'set arch i386:x86-64:intel' \
    -ex 'target remote localhost:1234' \
    -ex 'break start_kernel' \
    -ex 'continue' \
    -ex 'disconnect' \
    -ex 'set arch i386:x86-64' \
    -ex 'target remote localhost:1234'

I skończyliśmy!!

Dla jądra Moduły zobacz: jak debugować moduły jądra Linuksa za pomocą QEMU?

Dla Ubuntu 14.04, GDB 7.7.1, hbreak było potrzebne, break punkty przerwania oprogramowania były ignorowane. Już nie w 16.10. Zobacz też: https://bugs.launchpad.net/ubuntu / + source / qemu-kvm/ + bug/901944

Bałagan disconnect i co po nim jest, aby obejść błąd:

Remote 'g' packet reply is too long: 000000000000000017d11000008ef4810120008000000000fdfb8b07000000000d352828000000004040010000000000903fe081ffffffff883fe081ffffffff00000000000e0000ffffffffffe0ffffffffffff07ffffffffffffffff9fffff17d11000008ef4810000000000800000fffffffff8ffffffffff0000ffffffff2ddbf481ffffffff4600000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f0300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000

Powiązane wątki:

• https://sourceware.org/bugzilla/show_bug.cgi?id=13984 może be a GDB bug
• Zdalna odpowiedź pakietu ' g ' jest zbyt długa
• http://wiki.osdev.org/QEMU_and_GDB_in_long_mode osdev.org jest jak zwykle niesamowitym źródłem tych problemów
• https://lists.nongnu.org/archive/html/qemu-discuss/2014-10/msg00069.html

Zobacz też:

• https://github.com/torvalds/linux/blob/v4.9/Documentation/dev-tools/gdb-kernel-debugging.rst{[21]oficjalne jądro Linuksa "dokumentacja"
• jak debugować jądro Linuksa za pomocą GDB i QEMU?

Znane ograniczenia:

• jądro Linuksa nie obsługuje (i nawet nie kompiluje się bez łatek) z -O0: jak zoptymalizować jądro Linuksa i skompilować je za pomocą-O0?
• GDB 7.11 rozwali twoją pamięć przy niektórych typach uzupełniania kart, nawet po naprawie max-completions: przerwanie uzupełniania kart dla dużych binariów prawdopodobnie jakiś przypadek narożnika który nie był pokryty tą łatą. Więc {[11] } jest mądrą akcją przed debugowaniem. Gdy wypełniłem file<tab> dla filename argumentu sys_execve jak w: https://stackoverflow.com/a/42290593/895245

Jako ktoś, kto dużo pisze kod jądra muszę powiedzieć, że nigdy nie używałem kgdb, a rzadko używałem kprobów itp.

Jest to nadal często najlepszym podejściem do wrzucenia jakiegoś strategicznego printks. W nowszych jądrach {[1] } jest to dobry sposób, aby to zrobić bez spamowania dmesg.

User mode Linux (UML)

Https://en.wikipedia.org/wiki/User-mode_Linux

Kolejna wirtualizacja inna metoda, która umożliwia debugowanie kodu jądra.

UML jest bardzo pomysłowy: jest zaimplementowany jako ARCH, podobnie jak x86, ale zamiast używać instrukcji niskiego poziomu, implementuje funkcje ARCH za pomocą wywołań systemowych userland.

Rezultatem jest to, że jesteś w stanie uruchomić kod jądra Linuksa jako proces userland na Linuksie gospodarzu!

Najpierw zrób rootfs i uruchom go jak pokazano na: https://unix.stackexchange.com/questions/73203/how-to-create-rootfs-for-user-mode-linux-on-fedora-18/372207#372207

um defconfig ustawia CONFIG_DEBUG_INFO=y domyślnie (tak, jest to rzecz rozwojowa), więc jesteśmy w porządku.

On gość:

i=0
while true; do echo $i; i=$(($i+1)); done

Na serwerze w innej powłoce:

ps aux | grep ./linux
gdb -pid "$pid"

W GDB:

break sys_write
continue
continue

A teraz kontrolujesz licznik z GDB i widzisz źródło jako oczekiwane.

Plusy:

• w pełni zawarty w drzewie linii głównej jądra Linuksa
Bardziej lekki niż pełna emulacja systemu QEMU]}

Wady:

• Bardzo inwazyjne, ponieważ zmienia sposób kompilacji samego jądra.

  Ale interfejsy API wyższego poziomu poza specyfikacjami ARCH powinny pozostać niezmienione.

• Prawdopodobnie niezbyt aktywny: czy projekt user mode linux (UML) został zatrzymany?

Zobacz ponadto: https://unix.stackexchange.com/questions/127829/why-would-someone-want-to-run-usermode-linux-uml

Jesteście w błędzie, kgdb nadal działa dobrze dla najnowszego jądra, musisz zająć się konfiguracją jądra podzielonego obrazu, optymalizacją randomizacji.

Kgdb przez port szeregowy jest bezużyteczny, ponieważ żaden komputer obecnie nie obsługuje DB9 na porcie szeregowym płyty głównej, port szeregowy USB nie obsługuje trybu polling.

Nowa gra to kgdboe, poniżej znajduje się log trace:

Poniżej znajduje się maszyna hosta, vmlinux pochodzi z maszyny docelowej

root@Thinkpad-T510:~/KGDBOE# gdb vmlinux
Reading symbols from vmlinux...done.
(gdb) target remote udp:192.168.1.22:31337
1077    kernel/debug/debug_core.c: No such file or directory.
(gdb) l oom_kill_process 
828 mm/oom_kill.c: No such file or directory.
(gdb) l oom_kill_process 
828 in mm/oom_kill.c
(gdb) break oom_kill_process
Breakpoint 1 at 0xffffffff8119e0c0: file mm/oom_kill.c, line 833.
(gdb) c
Continuing.
[New Thread 1779]
[New Thread 1782]
[New Thread 1777]
[New Thread 1778]
[New Thread 1780]
[New Thread 1781]
[Switching to Thread 1779]

Thread 388 hit Breakpoint 1, oom_kill_process (oc=0xffffc90000d93ce8, message=0xffffffff82098fbc "Out of memory")
at mm/oom_kill.c:833
833 in mm/oom_kill.c
(gdb) s
834 in mm/oom_kill.c
(gdb) 

On peer target maszyna, poniżej znajduje się sposób na awarię i przechwycenie jej przez maszynę hosta

#swapoff -a
#stress -m 4 --vm-bytes=500m

Kgdb i gdb są prawie bezużyteczne do debugowania jądra, ponieważ kod jest tak zoptymalizowany, że nie ma żadnego związku ze źródłem orioginalnym i wiele varuiables jest zoptymalizowanych. To sprawia, że steppijng, a więc przejście przez źródło jest niemożliwe, badanie zmiennych jest niemożliwe i dlatego jest najbardziej punktowe.

Faktycznie jest gorzej niż bezużyteczny, to faktycznie daje fałszywą infoprmację tak odłączony jest kod, który ollooking do rzeczywistego kodu uruchomieniowego.

I Nie, Nie można wyłączyć optymalizacji w jądrze, nie kompiluje się.

Muszę powiedzieć, że wychodząc ze środowiska jądra windows, Brak porządnego debuggera jest bez sensu, biorąc pod uwagę, że istnieje śmieciowy kod do utrzymania.