x86,aarch64,arm

Ciro Santilli 0e9d1f25ad Almost working 8 anos atrás
buildroot @ 083c0735e9 338756a029 bak 8 anos atrás
host 690284a3bf Userland test programs 8 anos atrás
kernel_module 0e9d1f25ad Almost working 8 anos atrás
rootfs_overlay 7f6b148dc4 Split QEMU run, automate GDB debugging 8 anos atrás
.gitignore d45ceace5d 0 8 anos atrás
.gitmodules 338756a029 bak 8 anos atrás
README.md 0e9d1f25ad Almost working 8 anos atrás
bibliography.md 39d041484d delay with atomic works 8 anos atrás
build.md 8eb878c24e update 8 anos atrás
buildroot_config_fragment be9f56cc9b Use buildroot host gdb, consider QEMU and target GDB but give up for now 8 anos atrás
busybox_config_fragment bf3bb0cb18 fops read returns some data, busybox config frag for stat, bibliography start 8 anos atrás
introduction.md d45ceace5d 0 8 anos atrás
kernel_config_fragment 7f6b148dc4 Split QEMU run, automate GDB debugging 8 anos atrás
kmod.md d45ceace5d 0 8 anos atrás
run 0e9d1f25ad Almost working 8 anos atrás
rungdb 0e9d1f25ad Almost working 8 anos atrás
runqemu 0e9d1f25ad Almost working 8 anos atrás

README.md

Linux Kernel Module Cheat

Run one command, get into QEMU Buildroot BusyBox with several minimal Linux kernel 4.9 module example tutorials with GDB debug support. x86 and ARM guests supported. Tested in Ubuntu 14.04 - 16.10 hosts.

Usage:

sudo apt-get install qemu
./run

First build will take a while (GCC, Linux kernel).

QEMU opens up, and you can run:

root
insmod /hello.ko
insmod /hello2.ko
rmmod hello
rmmod hello2

This should print to the screen:

hello init
hello2 init
hello cleanup
hello2 cleanup

which are printk messages from init and cleanup methods of those modules.

Each module comes from a C file under kernel_module/. For module usage see:

head kernel_module/*.c

After the first build, you can also run just:

./runqemu

to save a few seconds. ./run wouldn't rebuild everything, but checking timestamps takes a few moments.

We use printk a lot, and it shows on the QEMU terminal by default. If that annoys you (e.g. you want to see stdout separately), do:

dmesg -n 1

See also: https://superuser.com/questions/351387/how-to-stop-kernel-messages-from-flooding-my-console

We use Buildroot's default kernel version, you can confirm it after build with:

grep BR2_LINUX_KERNEL_VERSION buildroot/.config

Text mode

Show serial output of QEMU directly on the current terminal, without opening a QEMU window:

./run -n

To exit, just do a regular:

poweroff

This is particularly useful to get full panic traces when you start making the kernel crashing :-)

In case of a panic, you want your terminal back with Ctrl + C, A and type quit. See also: http://stackoverflow.com/questions/14165158/how-to-switch-to-qemu-monitor-console-when-running-with-curses

See also: https://unix.stackexchange.com/questions/208260/how-to-scroll-up-after-a-kernel-panic

Debugging

To GDB the Linux kernel, first run:

./runqemu -d

This starts QEMU on the background of the shell, to prepare for running GDB.

If you want to break immediately at a symbol, e.g. start_kernel of the boot sequence, run:

./rungdb start_kernel

Now QEMU will stop there, and you can use the normal GDB commands:

l
n
c

To skip the boot, run just:

./rungdb

and when you want to break, do Ctrl + C from GDB.

To have some fun, you can first run inside QEMU:

/count.sh

which counts to infinity to stdout, and then:

Ctrl + C
break sys_write

And now you can control the counting from GDB:

continue
continue
continue

See also: http://stackoverflow.com/questions/11408041/how-to-debug-the-linux-kernel-with-gdb-and-qemu

If you are using text mode:

./runqemu -d -n

QEMU cannot be put on the background of the current shell, so you will need to open a separate terminal and run:

./rungdb

manually.

Kernel module debugging

Loadable kernel modules are a bit trickier since the kernel can place them at different memory locations depending on load other.

So we cannot set the breakpoints before insmod.

However, the Linux kernel GDB scripts offer the lx-symbols command, which takes care of that beautifully for us:

./runqemu -d
./rungdb

In QEMU:

insmod /fops.ko

In GDB, hit Ctrl + C, and note how it says:

scanning for modules in ../kernel_module-1.0/
loading @0xffffffffa0000000: ../kernel_module-1.0//fops.ko

That's lx-symbols working! Now simply:

b fop_write
c

In QEMU:

printf a >/sys/kernel/debug/kernel_module_cheat/fops

and GDB now breaks at our fop_write function!

Just don't forget to remove your breakpoints after rmmod, or they will point to stale memory locations.

TODO: why does break work_func for insmod kthread.ko not break the first time I insmod, but breaks the second time?

Bypassing lx-symbols

Useless, but a good way to show how hardcore you are. From inside QEMU:

insmod /fops.ko
cat /proc/modules

This will give a line of form:

fops 2327 0 - Live 0xfffffffa00000000

And then tell GDB where the module was loaded with:

Ctrl + C
add-symbol-file ../kernel_module-1.0/fops.ko 0xfffffffa00000000

ARM

The portability of the kernel and toolchains is amazing.

If you already have an x86 build present, first:

cd buildroot
mv output output.x86~

First ARM build:

./run -a arm

Run without build:

./runqemu -a arm

Debug:

./runqemu -a arm -d
# On another terminal.
./rungdb -a arm

ARM TODOs:

Table of contents

  1. Introduction
  2. Build
  3. kmod
  4. Bibliography
  5. Examples
    1. Host
    2. Buildroot
      1. Debugging
        1. hello
        2. hello2
        3. debugfs
        4. panic
      2. fops
      3. Asynchronous
        1. workqueue
        2. sleep
        3. kthread
        4. timer
        5. work_from_work