用 Zig 写的最小 Kernel

几乎所有 x86 系统都支持 BIOS 启动，包括使用模拟 BIOS 的基于 UEFI 的新机器。 这很好，因为你可以在上个世纪的所有机器上使用相同的启动逻辑。 但这种广泛的兼容性同时也是 BIOS 启动的最大弊端，因为这意味着 CPU 在启动前要进入一种名为实模式的 16 位兼容性模式，这样上世纪 80 年代的老式启动加载程序仍能正常工作。

实模式也称为实地址模式，是所有 x86 兼容 CPU 的一种运行模式。 该模式之所以得名，是因为实模式下的地址总是与内存中的实际位置相对应。 实模式的特点是：

1. 20 位分段内存地址空间（提供 1 MB 的可寻址内存）
2. 对所有可寻址内存、I/O 地址和外设硬件的无限制直接软件访问
3. 不支持内存保护、多任务处理或代码权限级别。

让我们从头开始：

1. 当你打开电脑时，它会从主板上的特殊闪存中加载 BIOS。
2. BIOS 运行硬件自检和初始化程序，然后寻找可启动磁盘。
3. 如果找到了，控制权就会转移到引导程序，即存储在磁盘开头的 512 字节可执行代码。大多数引导加载程序都大于 512 字节，因此引导加载程序通常会被分割成 512 字节的第一阶段和第二阶段。

引导加载程序必须确定内核映像在磁盘上的位置并将其加载到内存中。 它还需要先将 CPU 从 16 位实模式切换到 32 位保护模式，然后再切换到 64 位长模式，此时 64 位寄存器和完整的主内存可用。 第三个任务是从 BIOS 中查询某些信息（如内存映射）并将其传递给操作系统内核。

编写引导加载程序有点麻烦，因为它需要汇编语言，并且涉及到许多不那么直观的步骤，如 "将这个神奇的值写入这个处理器寄存器"。 因此，我们在这篇文章中并不涉及引导加载程序的创建，而且使用一个业界标准：Multiboot 协议。

为了避免每个操作系统实现自己的引导加载器，而引导加载器只能与单一操作系统兼容， 自由软件基金会于 1995 年创建了一个名为 Multiboot 的开放引导加载器标准。 该标准定义了引导加载程序和操作系统之间的接口，因此任何兼容 Multiboot 的引导加载程序都可以加载任何兼容 Multiboot 的操作系统。 参考实现是 GNU GRUB，它是 Linux 系统最常用的引导加载器。

Multiboot 标准目前有两个主要版本：

• Multiboot 1：最初的版本，广泛支持且使用较多。最新版是 0.9.6，发布于 2009 年。
• Multiboot 2：改进版本，增加了更多功能和灵活性，但使用相对较少。最新版是 2.0，发布于 2016 年。

在 Freestanding 环境中，没有操作系统来管理内存，因此需要手动指定代码和数据在内存中的位置，这时就需要用到链接器脚本（linker script）。它可以控制各个段的起始地址、大小和属性，从而满足特定的硬件或软件要求。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// File: linker.ld (lines 1-20)
ENTRY(_start)

SECTIONS {
    . = 1M;

    .text : ALIGN(4K) {
        /* We need to specify KEEP to prevent the linker from garbage-collecting the multiboot section. */
        KEEP(*(.multiboot))
        *(.text)
    }

    .rodata : ALIGN(4K) {
        *(.rodata)
    }

    .data : ALIGN(4K) {
        *(.data)
    }
}

让我们一起来解读一下上面的脚本：

• . = 1M; 这行设置当前位置计数器（Location Counter）为 1MB (1 Megabyte)。这意味着后续的段将被放置在 1MB 地址开始的内存区域。这通常是内核或引导加载器代码的常见起始地址。

• .text : ALIGN(4K) { ... } 这定义了一个名为 .text 的段，通常用于存储程序的代码（可执行指令）

  • ALIGN(4K) 这表示 .text 段的起始地址必须是 4KB 对齐。 这可以提高缓存性能，因为现代计算机通常以页为单位进行内存管理，而页大小通常是 4KB。
  • KEEP(*(.multiboot)) 这行指令告诉链接器保留所有标记为 .multiboot 的输入段。这通常用于保留 Multiboot 引导信息结构，确保它不会被优化掉。
  • *(.text) 这行指令将所有输入文件中的 .text 段内容链接到输出文件的 .text 段中。 * 是通配符，表示所有输入文件。

介绍完这两个文件，我们就可以用下面命令编译我们的内核：

1
2

zig build-exe -target x86-freestanding 02-01.zig -T linker.ld --name mini-kernel
file mini-kernel

mini-kernel: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, with debug_info, not stripped

编译成功后，我们就可以在 qemu 中启动它了：

1

qemu-system-x86_64 -kernel mini-kernel

呃… 它真的做了什么吗？ 有！ 是的，它做到了！ 它没有启动失败！ 好吧……但让它至少能像其他指南一样打印出 hello world。

通过 Godbolt 来输出汇编代码我们就可以发现端倪！问题出在 i*2 上，Zig 出于安全性考虑，数字在进行四则运算时会进行溢出检查，在溢出时直接 panic 退出，这就导致生成的汇编中会有一个 call example.panic 指令，而在上一节中，我们知道 Naked 修饰的函数不会生成函数序言（prologue），因此这里进行函数调用就会有问题。

知道了问题的原因，解决也就简单了。第一，我们可以通过 ReleaseFast 模式来跳过溢出检查。

1
2

zig build-exe -target x86-freestanding -O ReleaseFast 02-02.zig -T linker.ld &&
qemu-system-x86_64 -kernel 02-02

其次，我们可以手动设置函数序言：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// File: 02-03.zig (lines 23-45)
// 内核主函数
export fn _start() callconv(.Naked) noreturn {
    asm volatile (
        \\ push %ebp
        \\ jmp %[start:P]
        :
        : [start] "X" (&main),
    );
}

pub fn main() callconv(.C) void {
    // Direct memory access to the VGA Text buffer.
    var buffer: [*]volatile u8 = @ptrFromInt(0xB8000);
    const msg = "Hello World!";
    for (msg, 0..) |c, i| {
        buffer[i * 2] = c;
        buffer[i * 2 + 1] = 0xb;
    }

    // 死循环
    while (true) {}
}

这里利用了 Zig 支持的内敛汇编来对栈基指针 ebp 压栈，然后直接跳转到 &main 函数的地址处。

说明：在 0.11 之前的版本中，有些教程会用 @call(.{ }, main, .{}); 来调用 main 函数，但最新版已经不再支持，详见：Remove `stack` option from `@call`

1
2

zig build-exe -target x86-freestanding 02-03.zig -T linker.ld &&
qemu-system-x86_64 -kernel 02-03