Session 4: Kernel Debugging


Download and unzip the tasks archive sesiune-04 on the virtual machine.

  1. gdb
    • cd /usr/src/linux
    • file vmlinux
    • Kernel symbol table
      # nm vmlinux | grep sys_call_table
      # cat | grep sys_call_table 
    • Run gdb –quiet vmlinux
      • Dissasemble sys_fork function
      • Print x/x 0x123 where 0x123 is an address obtained above from the symbol table.
      • Use gdb to display the address and value of jiffies variable.
    • Debug dynamic modules:
      • Compile myproc module from 0-gdb directory with debug options make COPTS=-g.
      • Load the module insmod myproc.ko.
      • Obtain the module's load address cat /sys/module/myproc/sections/.text.
      • In gdb run: add-symbol-file myproc.o load_address.
      • Display the code/implementation of myproc_read implemented in the module (hint: list).
  2. sysrq-trigger
    • Use this file to generate the following events:
      • echo d > /proc/sysrq-trigger, display all currently held locks
      • echo m > /proc/sysrq-trigger, output current memory information to the console
      • echo p > /proc/sysrq-trigger, output the current registers and flags to the console
      • echo q > /proc/sysrq-trigger, display all active high-resolution timers and clock sources
      • echo c > /proc/sysrq-trigger, generate a kernel panic
    • Use dmesg to check the results.
  3. Penguin allocation
    • Follow the code in 1-penguin directory.
    • penguin.c implements a simple kernel modules that brings alive a penguin.
    • Do you notice any problems with the penguin module?
    • Use kmemleak to solve the problem:
      • Clear the list of all possible memory leaks:
        • echo clear > /sys/kernel/debug/kmemleak
      • insert penguin module: insmod penguin.ko
      • remove penguin module: rmmod penguin.ko
      • Trigger a memory scan:
        • echo scan > /sys/kernel/debug/kmemleak
      • Check possible memory leaks:
        • cat /sys/kernel/debug/kmemleak
  4. Linux kernel real memory leak
    • Reboot the system to cleanup the leaks information from the previous session
    • Use kmemleak to check all possible leaks existing after booting
    • cat /sys/kernel/debug/kmemleak
    • Explain why there is a memory leak in function udp_table_init?
  5. Slab debug
    • Follow the code in 2-crusher/ directory.
      • crusher.c is a simple module which allocates memory and accesses it in different forms.
      • Use CRUSH_MODE to generate the following types of errros:
        • use before init
        • use after free
  6. Stack size
    • Use the code in 3-eat-stack/ directory to determine the size of the stack.
      • Hints:
        • Make use of a buffer or make use of recursive calls.
  7. Netconsole and netcat
    • Netconsole module is already configured on the virtual machine in order to send kernel panic messages to the host to port 6000.
    • On the host, start listening for these messages using netcat nc -lu 6000.
    • On the virtual machine, generate a panic echo c > /proc/sysrq-trigger.
  8. HW breakpoint
    • In this example 4-hwbreak/ we use 3 modules in order to monitor the write accesses on a variable.
    • simple.ko module defines and exports myvar variable, simplet.ko modifies it and data_breakpoint.ko adds a hardware breakpoint in order to monitor the variable. Follow the steps below:
      • build simple.ko and load it: ./ simple; insmod simple/simple.ko
      • build data_breakpoint.ko and load it: ./ data_breakpoint; insmod data_breakpoint/data_breakpoint.ko ksym=myvar
      • modify simple/Kbuild in order to build simplet.ko and load it: ./ simplet; insmod simple/simplet.ko
      • follow the messages in dmesg.
    • We can also monitor other kernel variables by adding the associated name while loading data_breakpoint.ko: ksym=variable_to_monitor.
  9. Kprobes
    • Build and run the 3 samples in 5-kprobe/, one for each type of kprobe.
sesiuni/kernel/day-4.txt · Last modified: 2013/07/04 00:28 by dbaluta