从零写OS内核 | 电脑开机后，BIOS/UEFI/GRUB 是怎么把控制权交给 OS 的

你有没有想过这个问题：按下电源键的一瞬间，CPU 的 CS:IP 寄存器指向哪里？是谁把它设置成那个值的？为什么开机后屏幕亮起来，你看到的是一个选择菜单，而不是一片黑屏？

这不是魔法，是一条漫长的接力链——从 CPU 上电那一刻，到 GRUB 把控制权交给内核，中间经历了至少三个阶段：BIOS/UEFI 固件 → Bootloader（GRUB） → OS 入口点。每一棒都有严格交接手续，不是谁都能跑下一程的。

今天，我们来拆解这条链路——BIOS、UEFI、GRUB 是怎么一步步把控制权交到你写的 OS 代码手上的。

BIOS 时代的启动：0xFFFF0 是怎么来的

CPU 上电的第一跳

x86 CPU 上电后，第一件事不是读硬盘，是认死理——CS = 0xFFFF，IP = 0x0000，形成物理地址 CS << 4 + IP = 0xFFFF0。这个地址在 640KB 主内存之外（靠近 1MB 顶端），是留给 BIOS ROM 用的。

Bash

CPU 上电瞬间：
CS = 0xFFFF
IP = 0x0000
────────────────
物理地址 = 0xFFFF0（ROM BIOS 入口点）

BIOS ROM 在这个地址放了一条 jmp 指令，跳到真正的初始化代码。这就是整个系统软件的第一条指令——不是 Linux，不是 GRUB，是 BIOS 固化在 ROM 里的一条跳转。

POST 和硬件自检

BIOS 做的第一件正事是 POST（Power-On Self Test）：检查 CPU、内存、显卡、键盘控制器有没有问题。如果 POST 失败，你听到的是一串蜂鸣声（不同的蜂鸣模式代表不同的故障）；如果成功，屏幕会亮起来，显示厂商 Logo。

Bash

POST 检查顺序：
① CPU 测试（寄存器、标志位）
② 内存检测（通过 SPD 读取 DIMM 大小）
③ 显卡初始化（显示 BIOS 启动画面）
④ 键盘/鼠标/USB 初始化
⑤ CMOS 配置读取（启动顺序、频率设置）

实模式下的磁盘启动

POST 完成后，BIOS 按照启动顺序（Boot Order）依次尝试每种启动设备：

Bash

启动顺序（典型 CMOS 配置）：
1. NVMe SSD（UEFI 模式）
2. SATA HDD（UEFI 模式）
3. USB Drive（UEFI 或 Legacy）
4. 光驱（Legacy only）
5. 网络（PXE，Legacy）

对于传统 BIOS（Legacy）模式启动，BIOS 会读取磁盘的第一个扇区（MBR，0 柱 0 磁头 1 扇区，共 512 字节），把它加载到内存 0x7C00 处，然后检查最后 2 字节是否是 0x55AA（可启动标志）：

Bash

# 用 hexdump 看 MBR 的结尾标志
hexdump -C /dev/sda -n 512 | tail -2
# 输出：000001fe  00 00 00 00 00 00 00 00 00 00 00 00  aa 55
#                                                      ^^^^
#                                                      可启动标志 0x55AA

如果 MBR 有 0x55AA，BIOS 就跳转到 0x7C00 处执行——把控制权交给 Bootloader 的第一棒。

实模式内存布局（启动初期）

Bash

0x00000 ────────────────── 0x9FFFF：常规内存（640KB）
0xA0000 ────────────────── 0xBFFFF：VGA显存（128KB）
0xC0000 ────────────────── 0xFFFFF：硬件映射区
  0xC0000 - 0xC3FFF：VGA BIOS ROM（显卡固件）
  0xE0000 - 0xEFFFF：系统 BIOS 扩展（部分机器）
  0xF0000 - 0xFFFFF：系统 BIOS ROM（512KB，包含启动代码）
0xFFFF0：BIOS 入口点（CPU 上电跳到这里）
0x7C00：MBR 被加载的地址（GRUB 第一阶段代码从这里开始）

UEFI 时代：不再需要 MBR

BIOS 的历史局限

Legacy BIOS 有几个根本性缺陷：

只能读磁盘第一个扇区：512 字节塞进所有启动代码，根本不够用
实模式限制：只能访问 1MB 内存，无法驱动超过 2TB 的磁盘（用 48-bit LBA 才能超过）
没有安全验证：任何代码都能运行，rootkit 可以藏在 MBR 里

UEFI 的设计

UEFI（Unified Extensible Firmware Interface）用 GPT（GUID Partition Table）替代 MBR，用 EFI 分区（FAT32 文件系统）存储 Bootloader。

GPT 磁盘结构：

Bash

┌────────────────────────────────────────────────────────────┐
│ Protective MBR（兼容旧BIOS，指向GPT头）                      │
├────────────────────────────────────────────────────────────┤
│ GPT Header（位置在 LBA 1，包含分区表位置、分区数量等）          │
├────────────────────────────────────────────────────────────┤
│ 分区表（通常在 LBA 2-33，每个分区有唯一 GUID）                 │
├────────────────────────────────────────────────────────────┤
│ 分区 1：EFI System Partition（ESP，FAT32，≥100MB）           │
│ 分区 2：Linux 分区                                           │
│ 分区 N：...                                                  │
└────────────────────────────────────────────────────────────┘

ESP 分区里放的是 .efi 文件——不是裸二进制，是符合 PE/COFF 格式的可执行文件。这和 Windows 的 .exe 是同一套格式，所以 UEFI 能同时启动 Windows Boot Manager 和 GRUB。

UEFI 启动流程

Bash

① 上电 → UEFI 固件初始化（比 BIOS 快，因为它有 C 语言级别的驱动栈）
② 读取 NVRAM 里的 BootOrder（启动顺序列表）
③ 按顺序尝试加载 EFIBootBootX64.efi（默认）或 NVRAM 里注册的条目
④ 验证签名（Secure Boot）或直接执行（非 Secure Boot）
⑤ 找到 .efi 文件后，跳到它的入口点——控制权交给 Bootloader

Secure Boot 是 UEFI 的安全机制：固件里内置了微软/厂商的公钥，只有签名过的 .efi 才能启动（即使磁盘被拆走塞入另一台机器也启动不了）。

Bash

# 查看当前机器的 Secure Boot 状态（Linux）
cat /sys/firmware/efi/efivars/SecureBoot-* 2&gt;/dev/null
# 输出：5 0 0 0 表示 Secure Boot 已启用（数据第三个字节为 1）
mokutil --sb-state  # 更友好的查看方式

两个世界的分叉

Bash

Legacy BIOS 模式：
  MBR(512B) → Bootloader Stage 1 → Stage 2（GRUB） → Kernel

UEFI 模式（无 Secure Boot）：
  EFI System Partition → *.efi 文件 → Kernel（或 GRUB）

UEFI 模式（Secure Boot）：
  EFI System Partition → *.efi（签名验证） → Kernel（或 GRUB）

UEFI 不需要 MBR，所以 UEFI 模式下安装的系统，磁盘前 512 字节可能是空或只含 protective MBR（GPT 兼容层）。这也是为什么”用 MBR 修复工具修复 UEFI 安装的系统”通常无效——根本就没用 MBR。

GRUB：承上启下的 Bootloader

为什么需要 GRUB

问题来了：固件（BIOS 或 UEFI）只知道”加载某个扇区”或”执行某个 .efi 文件”，它怎么知道哪个文件是 Linux 内核？内核文件可能很大（10MB+），放不进一个扇区，也不可能让固件理解 ELF 格式。

答案是：需要一个中间人，来理解文件系统 + 加载内核。GRUB 就是这个中间人。

GRUB 的两阶段加载

第一阶段（Stage 1）：存放在 MBR 里（446 字节），只有最最基本的启动代码。它的工作是加载 Stage 1.5。

Stage 1.5（通常在 MBR 后的扇区，或嵌入在 GPT 的 BIOS Boot 分区）：这部分代码能理解文件系统（ext4/XFS/FAT），从而能读取 Stage 2 的文件（/boot/grub/normal.mod 等）。

Stage 2：真正的 GRUB 主程序，支持菜单、命令行、配置文件（grub.cfg）。

Bash

GRUB 加载链：
MBR(Stage 1, 446B) → 读文件系统 → Stage 1.5（理解分区格式）
                                       ↓
                                 Stage 2（grub.cfg、菜单）
                                       ↓
                              加载 Linux kernel + initramfs

GRUB 和 Multiboot 协议

GRUB 和 Linux 之间的”交接手续”靠 Multiboot 协议。内核文件在开始处放一个特殊的 header：

Asm

; multiboot.S（见 demos/multiboot）
.section .multiboot
.align 4

.long 0x1BADB002          /* magic = GRUB 认识这个值 */
.long 0x00010003          /* flags = 需要内存信息和图形模式 */
.long -(0x1BADB002 + 0x00010003)  /* checksum = 必须为零 */

GRUB 看到这 3 个 long（12 字节），就知道：

magic = 0x1BADB002：这个文件是 Multiboot 兼容的内核
flags = 0x00010003：告诉 GRUB”我需要哪些信息”（内存映射、命令行等）
checksum：校验 magic + flags 是否正确（防损坏）

交接时，GRUB 设置好寄存器：

eax = 0x2BADB002（magic，证明 GRUB 已加载）
ebx = boot_info 结构体指针（内存映射、命令行、模块列表等）
关闭保护模式之前的实模式环境，切换到平坦模型

GRUB 加载 Linux 内核的实际步骤

Bash

# /boot/grub/grub.cfg（简化）
menuentry &#039;Arch Linux&#039; {
    load_video
    set root=&#039;hd0,gpt2&#039;                    # 第二分区（Linux root）
    linux /boot/vmlinuz-linux root=/dev/sda2  # 加载内核镜像
    initrd /boot/initramfs-linux.img        # 加载临时文件系统
}

Bash

GRUB 加载 Linux 流程：
① 读取 vmlinuz（gzip 压缩的 ELF）
② 解压到 0x100000（1MB 处，这是 Linux 的惯例入口）
③ 读取 initramfs（cpio 格式的临时根文件系统）
④ 跳转到 0x100000，开始执行 Linux 的入口点

Linux 内核入口点：是 /arch/x86/boot/header.S 里的 _start。这段代码在 arch/x86/boot/compressed/ 里，职责是解压内核（如果启用了 CONFIG_KERNEL_GZIP），然后跳到真正的内核入口 startup_32 或 startup_64。

Bash

vmlinuz 结构（压缩内核）：
[compressed kernel image（gzip）] + [setup code + boot protocol header]

GRUB 跳到这里 → header.S 的 _start：
  ① 确认启动标志（0x01B0 处的 word）
  ② 设置 edx = boot_params 指针（内存布局信息）
  ③ 解压（如果需要）
  ④ 跳到 0x100000 + 偏移（真正的内核入口）

wandos 的第一条指令：boot.asm 分析

wandos 的 boot 代码在 /tmp/wandos/ 里（需要确认目录结构）。一个典型的 PC Bootloader 汇编如下（参考 PC Boot Protocol）：

Asm

; wandos/boot/boot.asm（参考结构）
bits 16

section .text
global _start

_start:
    ; CPU 上电后第一条指令在这里（GRUB 加载点）
    cli                         ; 关闭中断（保护模式切换前）
    xor ax, ax
    mov ds, ax
    mov es, ax
    mov ss, ax
    mov sp, 0x7C00             ; 设置栈（向下生长）

    ; 开启 A20 地址线（访问 1MB 以上内存）
    in al, 0x92
    or al, 2
    out 0x92, al

    ; 进入保护模式（GDT 已在 GRUB 或 wandos 设置）
    lgdt [gdt_descriptor]
    mov eax, cr0
    or eax, 1                   ; CR0.PE = 1（保护模式开启）
    mov cr0, eax

    ; 远跳转到 32 位代码段
    jmp 0x08:protected_mode

bits 32
protected_mode:
    ; 现在是平坦模型（4GB 线性地址空间）
    mov ax, 0x10                ; 数据段选择子
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    mov ss, ax

    ; 跳到 C 入口点 kernel_main()
    extern kernel_main
    call kernel_main

    ; 停机
    jmp $

wandos 和 Linux 的对比：

wandos 假设 GRUB（或其他 bootloader）已经建立了 GDT；Linux 有自己的 boot protocol，可以不依赖 GRUB 的 GDT
wandos 的入口是 kernel_main()（C 函数）；Linux 的入口是 startup_32（汇编），再做模式切换到 C 代码
wandos 是简化的教育内核，没有 initramfs 解压链路；Linux 的启动链路更复杂（有解压、ACPI 探测、多核 Init 等）

Linux 实践：观察自己的启动链路

查看 GRUB 菜单配置

Bash

# 查看当前系统的 GRUB 配置
cat /boot/grub/grub.cfg | grep -A5 &#039;menuentry&#039;

# 或者更友好的方式（不编辑文件）
grep &quot;^menuentry&quot; /boot/grub/grub.cfg

查看内核启动参数

Bash

# 当前内核的启动参数（GRUB 传给内核的）
cat /proc/cmdline
# 输出示例：
# BOOT_IMAGE=/boot/vmlinuz-linux root=/dev/sda2 mitigations=auto

这些参数就是 GRUB 的 linux /boot/vmlinuz... 行传给 Linux 的——Linux 在 /arch/x86/kernel/head_64.S 里解析这些参数。

手动查看 MBR 内容

Bash

# 读取当前磁盘的 MBR（仅前 512 字节）
dd if=/dev/sda bs=1 count=512 2&gt;/dev/null | hexdump -C | tail -5

# 分区表（MBR 里 64 字节分区表，从 0x1BE 开始）
# 每条分区记录 16 字节，最多 4 条（主分区）
dd if=/dev/sda bs=1 count=512 2&gt;/dev/null | hexdump -C | sed -n &#039;1p;2p&#039;

查看 UEFI 启动条目

Bash

# 用 efibootmgr 查看 UEFI NVRAM 里的启动条目
sudo efibootmgr -v

# 输出示例：
# BootOrder: 0001, 0000
# Boot0001* Arch Linux   HD(1,GPT,...)/File(EFIarchgrub.efi)
# Boot0000* Windows Boot Manager   HD(2,GPT,...)/File(EFIMicrosoftBootbootmgfw.efi)

手动触发 GRUB 命令行（观察启动过程）

Bash

# 重启，在 GRUB 菜单按 &#039;c&#039; 进入命令行模式
grub&gt; ls                        # 列出所有设备
grub&gt; ls (hd0,gpt1)/            # 查看第一个 GPT 分区内容
grub&gt; linux (hd0,gpt2)/boot/vmlinuz-linux root=/dev/sda2  # 手动加载内核
grub&gt; boot                      # 手动启动

从零实现：写一个最小化的 Multiboot 内核

参考 demos/multiboot/：

Asm

; multiboot.S — 最小 Multiboot 内核
.section .multiboot
.align 4
.long 0x1BADB002
.long 0x00010003
.long -(0x1BADB002 + 0x00010003)

.text
.global _start
.type _start, @function

_start:
    # GRUB 已经把 eax=0x2BADB002, ebx=boot_info 指针设置好
    movw $0x10, %ax
    movw %ax, %ds
    movw %ax, %es
    movw %ax, %fs
    movw %ax, %gs
    movw %ax, %ss
    movl $0x90000, %ebp
    movl %ebp, %esp
    cli
    call kernel_main
    jmp .

// main.c — 内核主函数
void kernel_main(unsigned long magic, void *boot_info) {
    if (magic != 0x2BADB002) while(1);
    // GRUB 成功加载了我们
}

编译并用 GRUB 启动：

Bash

as --32 multiboot.S -o multiboot.o
gcc -m32 -fno-pie -c main.c -o main.o
ld -m elf_i386 -Ttext 0x100000 -o kernel.elf multiboot.o main.o
grub-mkrescue -o kernel.iso kernel.elf
qemu-system-i386 -cdrom kernel.iso

踩坑与注意事项

坑 1：MBR 被破坏后系统无法启动

现象：重装 Windows 后，Linux 的 GRUB 消失了（Windows 安装程序会覆盖 MBR）。

原因：Windows 的安装程序只认 Windows，不扫其他 OS 的 Bootloader。

解决：用 Linux Live USB 启动，运行 grub-install /dev/sda 重建 GRUB。

Bash

# 从 Live USB 启动后
mount /dev/sda2 /mnt
grub-install --boot-directory=/mnt/boot /dev/sda

坑 2：UEFI + Legacy 混合模式导致启动混乱

现象：装了双系统后，有时进 Windows，有时进 GRUB菜单。

原因：有些机器的 CSM（Compatibility Support Module）同时启用了 UEFI 和 Legacy 模式，磁盘的 ESP 分区和 MBR 同时存在，启动优先级不稳定。

解决：在 BIOS/UEFI 设置里明确选”UEFI Only”或”Legacy Only”，不混用。

坑 3：GRUB 找不到内核（UUID 变了）

现象：换了硬盘或重新分区后，GRUB 报 “Unknown filesystem”。

原因：GRUB 用 UUID 或 PARTUUID 定位内核，grub.cfg 里的 UUID 和实际磁盘不匹配。

解决：用 blkid 查实际 UUID，手动更新 grub.cfg，或用 grub-mkconfig -o /boot/grub/grub.cfg 自动重建。

写在最后

从按下电源键到内核第一条指令，这条链路是接力赛，不是魔法：

Bash

CPU 上电 → BIOS/UEFI 固件 → MBR/ESP → GRUB Stage 1/2
→ Multiboot Header 验证 → GRUB 加载内核到 0x100000
→ 内核入口点（startup_32/startup_64）→ kernel_main()

GRUB 和内核之间靠 Multiboot 协议交接，magic + checksum + boot_info 结构体，这就是标准的”签证”。

wandos 的 boot 代码是简化版（依赖 GRUB 建 GDT），Linux 有完整的 boot protocol + 解压流程 + initramfs 多级加载——教育内核和工业内核的差距就在这里。

下篇预告（361）：下一个候选方向——第一个用户态进程（init 之前世：从内核启动到 /sbin/init 的完整链路），或者 TTY 与终端：键盘中断是怎么变成 shell 提示符的。你选哪个？

仓库：https://github.com/golang12306/os-kernel-from-scratch

动手环节

想深入理解本文内容？动手实践是最好的方式：

今天的目标：下载 wandos 代码仓库，找到 boot.asm，对比它和 Linux boot protocol 的差距，然后编译运行。

下载 wandos：

Bash

git clone https://github.com/zhangfuwen/wandos.git
cd wandos

找到对应模块：在 boot/ 目录下找到 boot.asm（或等效的启动汇编），读懂它的 GDT/保护模式切换逻辑

编译 Multiboot 内核（参考 demos/multiboot/）：

Bash

as --32 multiboot.S -o multiboot.o
gcc -m32 -fno-pie -c main.c -o main.o
ld -m elf_i386 -Ttext 0x100000 -o kernel.elf multiboot.o main.o
grub-mkrescue -o kernel.iso kernel.elf
qemu-system-i386 -cdrom kernel.iso

观察 QEMU 里的启动过程：在 GRUB 菜单按 c 进入命令行，手动 linux /boot/kernel.elf 看 GRUB 如何加载

提示：wandos 采用 C++ + x86 汇编实现，参考 boot/ 下的现有代码风格，注释清楚再提交。

仓库：https://github.com/golang12306/os-kernel-from-scratch

从零写OS内核 | 电脑开机后，BIOS/UEFI/GRUB 是怎么把控制权交给 OS 的

从零写OS内核 | 电脑开机后，BIOS/UEFI/GRUB 是怎么把控制权交给 OS 的

BIOS 时代的启动：0xFFFF0 是怎么来的

CPU 上电的第一跳

POST 和硬件自检

实模式下的磁盘启动

实模式内存布局（启动初期）

UEFI 时代：不再需要 MBR

BIOS 的历史局限

UEFI 的设计

UEFI 启动流程

两个世界的分叉

GRUB：承上启下的 Bootloader

为什么需要 GRUB

GRUB 的两阶段加载

GRUB 和 Multiboot 协议

GRUB 加载 Linux 内核的实际步骤

wandos 的第一条指令：boot.asm 分析

Linux 实践：观察自己的启动链路

查看 GRUB 菜单配置

查看内核启动参数

手动查看 MBR 内容

查看 UEFI 启动条目

手动触发 GRUB 命令行（观察启动过程）

从零实现：写一个最小化的 Multiboot 内核

踩坑与注意事项

写在最后

相关阅读

动手环节

赞过：

作者

评论

发表评论取消回复

从零写OS内核 | 电脑开机后，BIOS/UEFI/GRUB 是怎么把控制权交给 OS 的

从零写OS内核 | 电脑开机后，BIOS/UEFI/GRUB 是怎么把控制权交给 OS 的

BIOS 时代的启动：0xFFFF0 是怎么来的

CPU 上电的第一跳

POST 和硬件自检

实模式下的磁盘启动

实模式内存布局（启动初期）

UEFI 时代：不再需要 MBR

BIOS 的历史局限

UEFI 的设计

UEFI 启动流程

两个世界的分叉

GRUB：承上启下的 Bootloader

为什么需要 GRUB

GRUB 的两阶段加载

GRUB 和 Multiboot 协议

GRUB 加载 Linux 内核的实际步骤

wandos 的第一条指令：boot.asm 分析

Linux 实践：观察自己的启动链路

查看 GRUB 菜单配置

查看内核启动参数

手动查看 MBR 内容

查看 UEFI 启动条目

手动触发 GRUB 命令行（观察启动过程）

从零实现：写一个最小化的 Multiboot 内核

踩坑与注意事项

写在最后

相关阅读

动手环节

分享到：

赞过：

作者

评论

发表评论 取消回复

发表评论取消回复