• Slides

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 System.map | 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: ./build.sh simple; insmod simple/simple.ko
     • build data_breakpoint.ko and load it: ./build.sh data_breakpoint; insmod data_breakpoint/data_breakpoint.ko ksym=myvar
     • modify simple/Kbuild in order to build simplet.ko and load it: ./build.sh 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.