调试内核

本文默认读者已经通过 linux 源码编译得到内核镜像了, 即用于调试的 vmlinux 和用于启动的 bzImage

概述

操作系统内核仅仅用于提供管理硬件 CPU/内存/磁盘等最基本的能力, 只有操作系统内核是远远不够的, 裸内核仍然需要一些软件环境才能够使用. 因此需要一个根文件系统(root file system)来提供文件系统的支持.

initramfs 包含了一个最小的文件系统,它包括一些基本的工具和驱动程序, 比如说 ls cat mkdir 等等, 以便在系统启动后能够挂载更完整的文件系统. initramfs 可以分为两部分来理解

init 说明它是操作系统启动之后第一个执行的程序/脚本

ramfs 说明它是内存文件系统, 所有对于文件的读写操作都会记录在内存中, 随掉电消失, 不会持久化的存储

操作系统启动过程中为什么需要 initramfs 呢?

首先需要说明的是, 使用 initramfs 是可选的. 默认情况下,内核使用内置驱动程序初始化硬件,挂载指定的根分区,加载已安装的 Linux 发行版的 init 系统.然后,init 系统加载其他模块并启动服务,直到它最终允许您登录.这是一个很好的默认行为,对许多用户来说已经足够了

initramfs 通过一个临时的内存文件系统提供了早期的用户空间,可以做内核在引导过程中自己无法轻松完成的事情. 比如说:

挂载根分区(用于加密分区、逻辑分区和其他特殊分区)

提供简约的救援外壳(如果出现问题)

自定义启动过程(例如打印欢迎消息、启动启动等)

加载模块(例如第三方驱动程序)

迁移到早期用户空间是必要的,因为查找和安装真正的根设备很复杂.根分区可以跨多个设备(raid 或单独的日志).它们可以在网络上(需要dhcp,设置特定的MAC地址,登录服务器等).它们可以存在于可移动媒体上,具有动态分配的主要/次要数字和持续的命名问题,需要完整的 udev 实现来解决.它们可以被压缩、加密、写入时复制、环回装载、奇怪的分区等. 此外内核的核心模块放置于 /lib/modules/$(uname -r)/kernel/ 当中, 这些模块必须要根目录(/) 被挂载时才能够被读取.但是如果核心本身不具备磁碟的驱动程序时, 当然无法挂载根目录,也就没有办法取得驱动程序,因此造成两难的地步

比如 Ubuntu18.04 mini.iso 只有 70MB, 只包含了一个图形化的 Ubuntu 安装流程, 所有的软件包/内核都是从网络上下载的. 这种复杂性(不可避免地包括策略)在内核空间不好处理也不应该处理, 很适合在用户空间中完成相关的配置操作

正常的发行版启动都会经过两步

第一步是先用 initramfs 启动裸内核

第二步是在initramfs 中挂载真正的发行版根文件系统,并chroot过去

下面我们来完成一个简易但是完善的 linux 发行版的启动与调试过程

qemu

调试内核首先需要一个虚拟化的硬件模拟器, QEMU 是一个非常健壮的模拟器和仿真器, 对虚拟化技术的支持很好, 可以直接使用 apt 安装

sudo apt install qemu qemu-system qemu-kvm

也可以选择手动编译安装最新版的 qemu

从 qemu download 找到当前最新版本, 笔者目前最新版本为 9.0.1

sudo apt-get install git libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev ninja-build

下面的 --prefix 为最终安装的路径, 可以选择安装安装的位置, 笔者这里直接安装在 ~/qemu 下了

wget https://download.qemu.org/qemu-9.0.1.tar.xz
tar xvJf qemu-9.0.1.tar.xz
cd qemu-9.0.1
./configure --prefix=~/qemu --enable-kvm  --target-list=x86_64-softmmu
make -j`nproc`
sudo make install

Busybox

BusyBox 是一个轻量级的 Unix 工具箱,它集成了许多标准 Unix 工具的功能,并且可以运行在资源受限的系统上,例如嵌入式设备和网络路由器等.BusyBox 能够代替大多数标准 Unix 工具集的实现,从而减少了系统空间和资源的需求.

BusyBox 的工具集包括了数百个 Unix 工具,如 ls/cp/cat/grep/tar/gzip/awk/sed/vi/ping/telnet 等,它们都被打包成一个可执行文件.BusyBox 本身只有一个可执行文件,但它包含了大量的 Unix 工具,并且可以通过命令行参数来指定使用哪些工具.

busybox 在当系统出现故障没有办法正常登录解决, 特别是在关键组件被误删或损坏时(比如误删 GLIBC), 可以找到你的根文件系统所在的分区并挂载到一个目录, 然后将准备好的 BusyBox 可执行文件复制到挂载的根文件系统中, 在 chroot 环境中,创建一些符号链接,以便 BusyBox 能够模拟常见的 UNIX 工具, 然后就可以使用 BusyBox 提供的基本工具进行系统修复.

wget https://busybox.net/downloads/busybox-1.36.0.tar.bz2
tar xf busybox-1.36.0.tar.bz2
cd busybox-1.36.0/
make menuconfig

配置选项中勾选 Build Static Lib, 因为这一步只是制作一个简单的根文件系统, 此时还没有 glibc 等重要的 C 运行库, 所以没办法动态链接的运行, 暂时用静态链接将 glibc 打包进可执行文件

-> Settings
   -> [*] Build static binary (no shared libs)

如果要编译 32 位的 busybox, 需要在 settings 中为 CFLAGS LDFLAGS 添加 -m32 选项, 并且安装 32 位编译环境
sudo apt-get install gcc-multilib

make -j$(nproc)
make install

make 结束的时候会有如下的警告, 忽略即可

Static linking against glibc, can't use --gc-sections
Trying libraries: crypt m resolv rt
 Library crypt is not needed, excluding it
 Library m is needed, can't exclude it (yet)
 Library resolv is needed, can't exclude it (yet)
 Library rt is not needed, excluding it
 Library m is needed, can't exclude it (yet)
 Library resolv is needed, can't exclude it (yet)
Final link with: m resolv

编译得到的可执行文件保存在 _install/ 目录下, 我们可以进入这个目录的bin文件夹下使用 ll 看到一个busybox可执行文件和众多链接文件, 这个 busybox 就是之后需要使用的工具

制作initramfs

新建一个文件夹(workspace)用于后续的工作区

mkdir workspace
cd workspace

将之前的 linux kernel中的 arch/x86/boot/bzImage 和 _install/bin/busybox 拷贝到此目录下

前者可以创建软链接, 后者最好直接复制过来

此时的目录结构:

workspace/
├── bzImage
└── busybox

新建 initramfs 目录用于后续的磁盘启动

mkdir initramfs
cd initramfs
mkdir -p bin
mv ../busybox bin/
touch init
chmod +x init
cd ..

此时的文件结构如下所示, 我们将 busybox 移动到 /bin 目录下, 另外创建了一个带有执行权限的 init 文件

workspace/
├── initramfs
│   ├── bin
│   │   └── busybox
│   └── init

在 initramfs/ 中新建 init 文件用于启动, 将下面的内容复制到init中, 它的作用是设置一些基本的环境和挂载文件系统,并最终执行一个shell, 以便于在引导过程中提供一个临时的操作环境,以便进行一些必要的操作或调试

#!/bin/busybox sh

# initrd, only busybox and /init
BB=/bin/busybox

$BB --install -s /bin

mkdir -p dev etc lib mnt proc sbin sys tmp var

mount -t devtmpfs  devtmpfs  /dev
mount -t proc      proc      /proc
mount -t sysfs     sysfs     /sys
mount -t tmpfs     tmpfs     /tmp

exec 0</dev/console
exec 1>/dev/console
exec 2>/dev/console

echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
setsid cttyhack setuidgid 1000 sh

poweroff -d 0  -f

脚本中的命令简单解释一下:

busybox --install -s /bin: 将 busybox 包含的程序在 /bin 目录下创建软链接

mount: /dev /sys /proc /tmp 这些目录及其内部的文件并不是真实的磁盘文件, 而是在操作系统运行的过程中创建的文件, 它们的文件系统属于内存文件系统. 一方面为用户提供了内核相关的接口, 例如可以通过访问 /proc/<uid> 获取到某个进程的相关数据
这种内存文件系统的方式可以很有效的完成用户态和内核态的数据交流, 而不需要陷入内核或者定义复杂的 API 来完成交互, 只需要 open 打开文件来处理字符串即可

setsid cttyhack setuidgid 1000 sh: 效果是在一个新的、独立的会话中,以指定用户(UID为1000)的身份启动一个新的Shell会话,并且该会话有一个有效的控制终端
root 用户的 UID 为 0, 普通用户的 UID 从 1000 起

initd(或者叫init)是系统引导过程的第一个用户空间进程,负责启动和管理系统中的各个服务和进程.它通常由操作系统提供,并且具有更复杂的功能和管理能力,如根据不同的运行级别加载和管理服务.initd通常使用一系列的启动脚本来管理服务的启动/停止和重启等操作.给出的脚本不是initd进程本身,而是一个在引导过程中执行的自定义脚本,它可能具有特定的目的或需求,但不具备initd进程的全部功能和特性

现代 linux 发行版一般用的都是 systemd 作为守护进程

在根目录新建 Makefile, 复制如下内容

注意下面的 Makefile 代码复制过去之后还需要手动改一下空格为 \t, 不然会出错

.PHONY: init qemu clean debug

KERNEL = bzImage
INITRAMFS = initramfs.img
QEMU = qemu-system-x86_64
# 如果是自己编译的 qemu 可以使用自己的路径
# QEMU = ~/qemu/bin/qemu-system-x86_64

init:
    cd ./initramfs && find . | cpio -ov --format=newc | gzip -9 > ../$(INITRAMFS)

qemu:
    $(QEMU) \
          -kernel $(KERNEL) \
          -initrd $(INITRAMFS) \
          -m 1G \
          -nographic \
          -append "earlyprintk=serial,ttyS0 console=ttyS0"

debug:
    $(QEMU) \
          -kernel $(KERNEL) \
          -initrd $(INITRAMFS) \
          -m 1G \
          -nographic \
          -append "earlyprintk=serial,ttyS0 console=ttyS0" \
          -S \
          -s

clean:
    rm $(INITRAMFS)

简单解释一下这里的命令的含义

首先是后面这一段很长的find . | cpio -ov --format=newc | gzip -9 > ../initramfs.img
这个命令的作用是将当前目录下的所有文件和子目录,打包成一个 cpio 归档文件,并使用 gzip 压缩成一个压缩文件,最后保存到上级目录的 initramfs.img 文件中, 用于创建初始化内存文件系统(initramfs)
- find .: 查找当前目录(以及其子目录)下的所有文件和目录,输出它们的路径.
- cpio -ov --format=newc: 将 find 命令输出的路径列表作为输入,创建一个 cpio 归档文件.-o 表示创建归档文件,-v 表示显示详细信息,--format=newc 表示使用 newc 格式创建归档文件,该格式通常用于初始化内存文件系统(initramfs).
- gzip -9: 对 cpio 归档文件进行压缩,并且使用最高压缩比 -9 以达到最小化文件大小.
- 最后将压缩后的数据流输出到上级目录中的 initramfs.img 文件中,使用重定向符号 > 来实现.

-nographic 表示在终端中以无图形模式启动虚拟机,不使用图形界面.

-append "earlyprintk=serial,ttyS0 console=ttyS0" 表示向内核传递启动参数.其中,earlyprintk=serial,ttyS0 表示启用串口输出信息,console=ttyS0 表示将控制台输出定向到串口终端(ttyS0)上.

最终的文件结构如下所示

QEMU 启动

制作initramfs

make init

如果报错 cpio 找不到的话先下载 sudo apt install cpio

执行之后会得到 initramfs.img

使用qemu开始模拟

make qemu

成功启动后按下enter进入命令行, 使用ls查看目录结构, 也可以在这个命令行中测试一些内容, 这些常用命令都是 busybox 提供的支持

退出 QEMU 模拟: 使用 ctrl + A 然后按下 x

Vscode + gdb

启用调试内核只需要

make debug

TIP
调试时不要使用 qemu 的 -enable-kvm, 不然也没办法无法正确的插入断点
正常执行的话不调试可以在 qemu 启动时加上 -enable-kvm -cpu host 大大加速启动

"-S"选项表示在启动时暂停虚拟机的执行.它使得虚拟机在启动后立即进入调试模式,并等待调试器连接. "-s"选项表示在启动时打开一个GDB服务器,监听本地的1234端口.这个选项与"-S"选项一起使用,用于配合调试器进行调试

如果没有冲突的话默认使用 1234 端口即可, 否则添加 -gdb tcp::12345 进行端口调整

你可以在一个终端中在 workspace 目前下使用 make qemu, 此时运行会卡住

然后再另一个终端中在 linux6.6 目前下使用 gdb vmlinux 调试
进入gdb后连接1234端口
```
(gdb) target remote :1234
```
在start_kernel处打一个断点(此函数位于init/main.c), 然后继续
```
(gdb) b start_kernel
(gdb) c
```

当然, 这种方法很原始, 笔者更倾向于使用带 GUI 的更加方便的vscode来进行调试

生成源码标签

首先阅读代码的时候没有什么智能提示和补全, 这是因为需要生成智能补全的头文件, 高版本的内核提供了一个脚本就可以直接得到 compile_commands.json

linux 默认提供了 make gtags 生成源码标签, 我们不使用

python3 ./scripts/clang-tools/gen_compile_commands.py

# 如果是老版本linux这个文件的位置在
python3 ./scripts/gen_compile_commands.py

等待一段时间运行结束之后得到 compile_commands.json

如果没有找到这个脚本可以使用 Bear 来在编译时生成脚本

sudo apt install bear
bear -- <之前的 make 命令>
# bear -- make -j`nproc`

默认的 Vscode C++ 插件都可以索引到根目录下的 compile_commands.json, 但可能还是会有一些报错如下所示, 这是因为 compile_commands.json 中的编译选项有一些无法识别的东西

如果读者使用的是 clangd 的话可以直接设置它的配置文件, 创建 ~/.config/clangd/config.yaml 文件, 该配置的含义是忽略无法识别的编译选项, 大部分无法识别的编译参数都是以 -m -f 开头的

CompileFlags:
  Add: -Wno-unknown-warning-option
  Remove: [-m*, -f*]

如果使用的是微软的 c++ 插件的话可以手动将这个文件中的这几个编译选项删除, 使用如下命令直接修改 compile_commands.json

sed -i 's/\(-mpreferred-stack-boundary=3\|-mindirect-branch=thunk-extern\|-mindirect-branch-register\|-mindirect-branch-cs-prefix\|-fno-allow-store-data-races\|-fconserve-stack\)//g' compile_commands.json
sed -i 's/-mfunction-return=thunk-extern//g' compile_commands.json
sed -i 's/-fzero-call-used-regs=used-gpr//g' compile_commands.json
sed -i 's/-fsanitize=bounds-strict//g' compile_commands.json
sed -i 's/-mrecord-mcount//g' compile_commands.json

然后就没有报错了, 整个代码看起来很清爽

NOTE
没有报错指大部分文件都没有明显的警告了, 如果点开一些头文件还是可以看到找不到符号的问题, 这是因为有一些头文件引用不规范, 暂且搁置

考虑到其他内核版本可能使用了不同的编译选项, 读者可以根据 clangd 的提示信息从中删除或修改对应的内容

sed -i 's/your warnning command//g' compile_commands.json

接下来配置调试程序, 新建.vscode/launch.json, 复制如下的代码, 设置调试的名称是 qemu-kernel-gdb, 使用本机的1234端口映射, 调试 vmlinux 文件

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "qemu-kernel-gdb",
            "type": "cppdbg",
            "request": "launch",
            "miDebuggerServerAddress": "127.0.0.1:1234",
            "program": "${workspaceFolder}/vmlinux",
            "targetArchitecture": "x64",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "logging": {
                "engineLogging": false
            },
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "text": "dir .",
                    "ignoreFailures": false
                },
                {
                    "text": "add-auto-load-safe-path ./",
                    "ignoreFailures": false
                },
                {
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }
    ]
}