Linux kernel调试

2017-05-09 21:39

本文发自 http://www.binss.me/blog/how-to-debug-linux-kernel/，转载请注明出处。

debug分为两大流派。打log流和断点流。

printk

对于小程序来说，打log太爽了，我可以花式打log，每行插一行log，一次加一行log。

在头文件<linux/kernel.h>中定义了 8 种可用的日志级别字符串：KERN_EMERG，KERN_ALERT，KERN_CRIT，KERN_ERR，KERN_WARNING，KERN_NOTICE，KERN_INFO，KERN_INFO。共有 8 种优先级，用户可以根据需要进行配置

KERN_EMERG    /* system is unusable                   */
KERN_ALERT    /* action must be taken immediately     */
KERN_CRIT     /* critical conditions                  */
KERN_ERR      /* error conditions                     */
KERN_WARNING  /* warning conditions                   */
KERN_NOTICE   /* normal but significant condition     */
KERN_INFO     /* informational                        */
KERN_DEBUG    /* debug-level messages                 */

打log：

printk(KERN_DEBUG "%d", HZ);

为了防止log太多撑爆ring buffer，启动时使用参数log_buf_len=104857600来指定buffer大小，这里为100M。

注意启动参数不要带 quite 和 splash。

QEMU + GDB

打log固然爽，然而对于kernel这种"程序"，每次rebuild可以等半天。每次调试都要不断加printk和rebuild显然不实际，于是考虑使用GDB进行动态调试。由于是调试kernel，在不考虑kGDB等方法的情况下，最简单的是跑一个虚拟机，然后GDB远程连上去。QEMU为此提供了较好的支持。

编译kernel

为了能够动态调试kernel，在编译前需要进行相应的配置，流程如下：

make mrproper
make x86_64_defconfig

cat <<EOF >.config-fragment
CONFIG_DEBUG_INFO=y
CONFIG_GDB_SCRIPTS=y
EOF

./scripts/kconfig/merge_config.sh .config .config-fragment

make -j $(nproc)

这里首先清理掉编译生存的文件，重新产生一个配置文件(.config)，并和配置了DEBUG的.config-fragment进行合并，最后有多少个核就开多少路进行编译。

注意.config很重要，先前我直接拷贝了/boot/config-xxx(当前kernel的配置)到.config，最后编译后发现无论是break(通过修改内存产生debug异常来断点)还是hbreak(通过debug寄存器来设置断点)都无法断点。只能通过make x86_64_defconfig生成一份新的配置，才能成功GDB。不知道因为哪个选项导致在gdb中无法断点，苦查无果......

2017.4.11更新

今晚洗澡的时候回想起这个问题，打算花点时间解决之。手头有两份文件，一份是原kernel的配置文件 .config_old，无法断点；另一份是通过make x86_64_defconfig新生成的配置文件 .config_new，可以断点，但缺乏一些配置导致编译的kernel无法带起物理机。于是想通过对比的方式找出问题所在。

结果一看，.config_old有8000行，.config_new有4000行，用diff一比发现一大堆不同，如果研究每一个diff那今晚不用睡了。于是决定暴力地使用二分查找法：每次用 .config_old 替换掉 .config_new 一半的配置条目，看编译后能否成功断点。

经过若干次查找后发现问题出在 Performance monitoring 里面，怀疑是以下几行出了问题：

CONFIG_RELOCATABLE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_RANDOMIZE_MEMORY=y
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa

是否是因为ASLR的原因可能会导致gdb无法断到正确的位置？Google一下发现这篇文章：https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.8-ASLR-Kernel-Mem-Sects，说是4.8引进了 CONFIG_RANDOMIZE_MEMORY 的新特性：

randomizing the virtual address space of kernel memory sections, the goal is to mitigate predictable memory locations.

于是利用 make menuconfig把 Processor type and features -> Randomize the kernel memory sections 关了，重新编译后发现依然无法断点。干脆把其父级选项 Randomize the address of the kernel image (KASLR) 也关了，这时终于好了。此时查看 .config 发现少了以下两行配置：

CONFIG_X86_NEED_RELOCS=y
CONFIG_RANDOMIZE_MEMORY=y

个人猜测是内存的重新布局导致无法成功断点。虽然开48核编译kernel每次只需几分钟，但前后调试还是花费了两个小时，蛋疼。

调试kernel

通过QEMU跑一个VM来加载kernel，同时启动gdbserver提供调试信息。在宿主机中通过连接该server来进行调试。命令为：

sudo qemu-system-x86_64 -m 2048 -kernel /home/binss/work/GDB-Kernel/arch/x86/boot/bzImage -initrd ~/work/initrd.img-4.4.0-66-generic -gdb tcp::8889 -nographic -serial mon:stdio -append 'console=ttyS0' -S --enable-kvm

其中kernel用来指定kernel的镜像文件，initrd用来指定initramfs，gdb用于启动gdbserver并指定监听的端口(也可以用-s来监听1234端口)，-nographic -serial mon:stdio -append 'console=ttyS0'用来指将输出重定向到当前终端，便于观察kernel运行时的输出。S表示在开始的时候停止直到通过gdb输入c才继续运行。

在运行过程中随时可以通过Ctrl-A + C 来切换到qemu monitor进行操作(重复操作退出qemu monitor)，如输入quit可以结束当前VM。

启动后，在另一个shell中cd到编译kernel的目录下，启动gdb，依次执行以下命令：

add-auto-load-safe-path /home/binss/work/GDB-Kernel/
file /home/binss/work/GDB-Kernel/vmlinux
directory /home/binss/work/GDB-Kernel
target remote:8889

这里从当前目录的vmlinux(带有符号信息的kernel，巨达几百M)中加载符号表。也可以把以上命令保存到当前目录(/home/binss/work/GDB-Kernel/)的.gdbinit中，然后在~/.gdbinit中添加：

add-auto-load-safe-path /home/binss/work/GDB-Kernel/.gdbinit

这样在gdb启动时就会自动执行以上命令。

然后我们就能够通过函数名进行断点了，比如断在入口：

hbreak start_kernel
c

注意对于QEMU模拟的VM，可以使用break，但对于KVM模拟的VM，需要使用hbreak。

挂载磁盘

前面的指令拉起的VM会挂在initramfs，因为没有指定要挂载的磁盘，可以通过hda挂载已有磁盘并配置root参数，从而成功进入某个虚拟机：

sudo qemu-system-x86_64 -m 2048 -kernel /home/binss/work/KVM-Learning/arch/x86/boot/bzImage -initrd ~/work/initrd.img-4.4.0-66-generic -hda myvm2.img -gdb tcp::8889 -nographic -serial mon:stdio -append 'root=/dev/sda1 console=ttyS0' --enable-kvm

当然为了加强鲁棒性，建议使用UUID来指定root设备，UUID可以在进入系统后查询/boot/grub/grub.cfg得到。

sudo qemu-system-x86_64 -m 2048 -kernel /home/binss/work/KVM-Learning/arch/x86/boot/bzImage -initrd ~/work/initrd.img-4.4.0-66-generic -hda myvm2.img -gdb tcp::8889 -nographic -serial mon:stdio -append 'root=UUID=02cf5ccd-f57f-4b25-b923-add3adb5d6c3 console=ttyS0' --enable-kvm

调试模块

对于内核模块，我们同样能够通过虚拟机的方式对其进行GDB。首先需要确保模块已被加载，对于自行编译的模块，可以通过scp等方式将文件发到guest中，通过insmod进行安装。注意需要保证是在当前kerenl的目录下编译模块，确保它们的版本相同。

然后需要定位模块地址(可能没有data和bss)：

sudo cat /sys/module/kvm/sections/.text
sudo cat /sys/module/kvm/sections/.data
sudo cat /sys/module/kvm/sections/.bss

结果：

binss@ubuntu:~$ sudo cat /sys/module/kvm/sections/.text
0xffffffffa00e4000
binss@ubuntu:~$ sudo cat /sys/module/kvm/sections/.data
0xffffffffa0143000
binss@ubuntu:~$ sudo cat /sys/module/kvm/sections/.bss
0xffffffffa0152140

然后在host的GDB中用这些地址加载模块：

(gdb) add-symbol-file ~/work/GDB-Kernel/arch/x86/kvm/kvm.ko 0xffffffffa00e4000 -s .data 0xffffffffa0143000 -s .bss 0xffffffffa0152140
add symbol table from file "/home/binss/work/GDB-Kernel/arch/x86/kvm/kvm.ko" at
    .text_addr = 0xffffffffa00e4000
    .data_addr = 0xffffffffa0143000
    .bss_addr = 0xffffffffa0152140
(y or n) y
Reading symbols from /home/binss/work/GDB-Kernel/arch/x86/kvm/kvm.ko...done.

用同样的方式加载kvm-intel的符号信息：

sudo cat /sys/module/kvm_intel/sections/.text
sudo cat /sys/module/kvm_intel/sections/.data
sudo cat /sys/module/kvm_intel/sections/.bss

结果：

binss@ubuntu:~$ sudo cat /sys/module/kvm_intel/sections/.text
0xffffffffa01a3000
binss@ubuntu:~$ sudo cat /sys/module/kvm_intel/sections/.data
0xffffffffa01cb000
binss@ubuntu:~$ sudo cat /sys/module/kvm_intel/sections/.bss
0xffffffffa01cbec0

加载：

(gdb) add-symbol-file ~/work/GDB-Kernel/arch/x86/kvm/kvm-intel.ko 0xffffffffa01a3000 -s .data 0xffffffffa01cb000 -s .bss 0xffffffffa01cbec0
add symbol table from file "/home/binss/work/GDB-Kernel/arch/x86/kvm/kvm-intel.ko" at
    .text_addr = 0xffffffffa01a3000
    .data_addr = 0xffffffffa01cb000
    .bss_addr = 0xffffffffa01cbec0
(y or n) y
Reading symbols from /home/binss/work/GDB-Kernel/arch/x86/kvm/kvm-intel.ko...done.

然后打断点：

(gdb) hb vcpu_enter_guest
Hardware assisted breakpoint 1 at 0xffffffffa0103d37: file ./arch/x86/include/asm/processor.h, line 482.
(gdb) hb vmx_vcpu_run
Hardware assisted breakpoint 2 at 0xffffffffa01b30e0: file arch/x86/kvm/vmx.c, line 8798.
(gdb) c
Continuing.

然后就可以进行调试了。在VM中运行：

qemu-img create -f qcow2 mytest.img 5G
sudo qemu-system-x86_64 -cpu host -hda mytest.img -boot c -nographic -serial mon:stdio -vnc :1 -smp 1 -m 2048 --enable-kvm

回到gdb：


Thread 2 hit Breakpoint 1, vcpu_run (vcpu=<optimized out>)
    at /home/binss/work/GDB-Kernel/arch/x86/kvm/x86.c:6788
6788                            r = vcpu_enter_guest(vcpu);
(gdb) p vcpu
$1 = <optimized out>
(gdb) c
Continuing.

Thread 2 hit Breakpoint 2, vmx_vcpu_run (vcpu=0xffff8800778a0000)
    at /home/binss/work/GDB-Kernel/arch/x86/kvm/vmx.c:8798
8798    {
(gdb) p vcpu
$5 = (struct kvm_vcpu *) 0xffff8800778a0000
(gdb) n
8799            struct vcpu_vmx *vmx = to_vmx(vcpu);
(gdb) n
8803            if (unlikely(!cpu_has_virtual_nmis() && vmx->soft_vnmi_blocked))
(gdb) p vmx
$6 = (struct vcpu_vmx *) 0xffff8800778a0000

缺陷在于编译kernel时强制采用了 -O2 进行编译，导致一些值被优化后显示为<optimized out>，可以考虑反汇编。