实现一个简单的 MBR#

最后，让我们写一个简单的程序来验证一下我们所学到的理论知识的正确性。

项目结构为：

1
.
2
├── boot
3
│   └── mbr.s
4
└── Makefile

1
section mbr vstart=0x7c00
2
  mov ax, 0x0600 ; clear screen
3
  mov bh, 0x07   ; color attribute 0x07
4
  xor cx, cx     ; upper left corner
5
  mov dx, 0x184f ; bottom right corner
6
  int 0x10
7

8
  mov ah, 0x03   ; get cursor position
9
  xor bh, bh     ; video page 0
10
  int 0x10
11

12
  mov cx, 0x03   ; length of string
13
  mov ax, 0x1301 ; write string, move cursor
14
  mov bx, 0x07   ; video page 0, color attribute 0x07
15
  lea bp, [msg]  ; ES:BP is the pointer to string
16
  int 0x10
17

18
  jmp $
19

20
  msg db "MBR"
21

22
  times 510-($-$$) db 0
23
boot_flag:
24
  dw 0xAA55

以上，有关 int 0x10 视频中断的用法可以参考 INT 10 - Video BIOS Services.

这里我不得不吐槽一句：AT&T 语法珍尼 🐴 屎……

更有趣的是：

Intel Syntax Support

Up until v2.10 of binutils, GAS supported only the AT&T syntax for x86 and x86-64, which differs significantly from the Intel syntax used by virtually every other assembler. Today, GAS supports both syntax sets (.intel_syntax and the default .att_syntax), and even allows disabling the otherwise mandatory operand prefixes ’%’ or ’$’ (…_syntax noprefix). There are some pitfalls - several FP opcodes suffer from a reverse operand ordering that is bound to stay in there for compatibility reasons, .intel_syntax generates less optimized opcodes on occasion (try mov’ing to %si…).

It is generally discouraged to use the support for Intel Syntax because it can subtly and surprisingly different than the real Intel Syntax found in other assemblers. A different assembler should be considered if Intel Syntax is desired.

你可知我有多无语……我反复用 GAS 重构 nasm，用 nasm 重构 GAS……最终，也还是没有活下来，我还是被这狗屎语法打倒了。学到了：珍惜生命，远离 GAS……不过倔强的精神告诉我，我以后大概还是会用 GAS 来重构，至于原因……Linux 内核用的就是这个……什么是自虐？我这就是……

1
AS = nasm
2
DD = dd bs=512 conv=notrunc
3
IMG = exordium.img
4
IMG_SIZE = 60M
5

6
all: boot/mbr create_img write_mbr
7

8
boot/mbr: boot/mbr.asm
9
 $(AS) -I boot -o $@ $<
10

11
create_img:
12
 qemu-img create -f raw $(IMG) $(IMG_SIZE)
13

14
write_mbr: boot/mbr
15
 $(DD) if=$< of=$(IMG) count=1
16

17
clean:
18
 rm -rf boot/mbr
19
 rm -f $(IMG)

使用 make clean && make 编译上述程序，并生成系统镜像。

之后，使用这个 start.sh 来模拟：

1
#!/bin/bash
2

3
IMG="exordium.img"
4

5
qemu-system-i386 -drive file=$IMG,format=raw,if=ide,index=0 -s -S -monitor stdio

使用下面这个 debug.sh 开启 gdb 以调试：

1
#!/bin/sh
2

3
gdb -ix gdb/.gdbinit \
4
  -ex 'set tdesc filename gdb/target.xml' \
5
  -ex 'target remote localhost:1234'

我们 gdb 中直接 (c) continue，看到 MBR 三个大字被输出在屏幕上，就意味着我们成功地向 MBR 迈出了第一步，壮举！

TIP

如果你通过 gdb 查看开机后运行的第一条指令，会发现这条指令并不符合我们的预期，这是因为 gdb 是按照 32-bit 指令格式进行解析指令的，而不是 16-bit 指令格式。

所以如果你想查看开机后运行的第一条指令的话，可以在启动虚拟机的指令后面加上 -monitor stdio 参数，之后在 qemu 控制台使用 x/10i $cs*16+$eip 指令来进行查看。

结果如下：

(qemu) x/10i $cs*16+$eip
0x000ffff0:  ea 5b e0 00 f0           ljmpw    $0xf000:$0xe05b
0x000ffff5:  30 36 2f 32              xorb     %dh, 0x322f
0x000ffff9:  33 2f                    xorw     (%bx), %bp
0x000ffffb:  39 39                    cmpw     %di, (%bx, %di)
0x000ffffd:  00 fc                    addb     %bh, %ah
0x000fffff:  00 00                    addb     %al, (%bx, %si)
0x00100001:  00 00                    addb     %al, (%bx, %si)
0x00100003:  00 00                    addb     %al, (%bx, %si)
0x00100005:  00 00                    addb     %al, (%bx, %si)
0x00100007:  00 00                    addb     %al, (%bx, %si)

其实还有别的方法，比如直接用 bochs，它很好的支持 16-bit 指令等内容，你也可以手动 patch qemu，或者简单点，如果你还是想用 qemu + gdb 的话，在我的项目根目录下有一个 gdb 目录，包含了 16-bit 调试的拓展脚本，并且可以自动在进入保护模式后切换到 32-bit 架构，实现正确解析不同架构之间的指令。

参考：The only proper way to debug 16-bit code on Qemu+GDB.

Loader，我们的救星#

由于 MBR 受限于 512 字节大小的空间，显然，这么点小小的空间肯定不足以我们将内核加载进内存并运行。所以一个很自然的想法就是，实现一个 Loader，用它来初始化环境并加载内核。

Loader 应该被 MBR 从硬盘读取到内存后执行，那我们应该将 Loader 写在硬盘中什么位置呢？我们知道 MBR 已经占据了第 0 扇区（LBA 扇区从 0 开始编号），那我们把它放到第 1 扇区？当然可以，但是离得那么近，心理多少有点不踏实，还是隔开点好了……那就放到第 2 扇区好啦～那么现在的问题是，我们把它加载到哪里好呢？理论上任何一块空闲空间都可以，参考实模式下的 1MB 内存布局可知，0x0500~0x7BFF 和 0x7E00~0x9FBFF 都是空闲内存。由于未来 Loader 中需要定义一些数据结构，比如 GDT，这些数据结构将来的内核还需要使用，所以 Loader 加载到内存后不能被覆盖；其次，随着我们不断添加功能，内核必然越来越大，其所在的内存地址也会向越来越高的的地方发展，难免会超过可用区域的上限，所以应该尽量把 Loader 放在低处，多留一些空间给内核。但……我选择效仿 Linux 内核的设计，把它加载到了 0x90000 这个位置，大家随意～

有关硬盘的操作，可以参考 AT Attachment with Packet Interface.

至于代码嘛……如果我每次新增了什么代码都复制一份贴到博客里显然有点多余，显得过于杂乱了。所以劳烦您自行阅读我提交的 source code. 仓库地址在 前言 底部已经给出。

进入保护模式#

一个新的模式的出现一定是为了取代旧有的模式，它一定是为了解决原先模式的一些缺陷而生的。

实模式是在有了 32-bit CPU 后才提出的，和纯粹的 16-bit CPU，8086 等无关。提出「实模式」的概念只是为了和有了 32-bit CPU 之后诞生的「保护模式」相区分，仅此而已。另外，实模式的运行环境是 16-bit，而保护模式的运行环境是 32-bit.

虽然有了保护模式，但之前实模式下的程序还得兼容，因此在「实模式」和「保护模式」之间还有个过渡模式，即「虚拟 8086」模式。

简单罗列一些实模式下的缺陷：

1. 实模式下操作系统和用户程序处于同一特权级，这哥俩平起平坐，没有区别对待。
2. 用户程序所引用的地址都是指向真实的物理地址，也就是说逻辑地址等于物理地址，实实在在的指哪打哪。
3. 用户程序可以自由修改段基址，可以不亦乐乎地访问所有内存，没人拦得住。
4. 访问超过 64KB 的内存区域时要切换段基址，转来转去容易晕乎。
5. 一次只能运行一个程序，无法充分利用计算机资源。
6. 共 20 条地址总线，最大可用内存为 1MB，这即使在当时也不够用。

前三点属于安全缺陷，第四、五点是使用方面的缺陷，似乎当时还可以勉强忍受一下，但最后一条就是硬伤，随着计算机事业的发展，程序对内存的需求必然越来越大，如果还是 1MB 内存，那真的是束手无策。

CPU 发展到 32-bit 后，地址总线和数据总线也发展到了 32-bit，其寻址空间达到了 $2^{32} =4294967296$ 字节，也就是 4GB 范围。寻址空间上去了，寻址方法还是老一套的「段基址:段内偏移地址」，因此如果还是维持 16-bit 的寄存器大小，肯定无法承担 4GB 的寻址重任。因此，保护模式下寄存器宽度也得到了提升，除段寄存器外，通用寄存器、指令指针寄存器和标志寄存器都由原先的 16-bit 扩展到了 32-bit，这样一来，单独的一个寄存器就可以访问到 4GB 空间的每一个角落，段地址可以为 0，开启了「平坦模式」的时代，大大方便了开发者的工作。

至于保护模式中对安全性的改进，主要是体现在段寄存器的用途上面。保护模式建立了 全局描述符表 (Global Description Table, GDT) 的概念，其中每一个表项称为段描述符，大小为 8 字节，用来描述各个内存段的起始地址、大小和权限等信息，当有实际动作在这片内存上发生时，CPU 就根据这些属性来检查动作的合法性，从而起到了保护的作用。GDT 存储在内存中，由 GDTR 寄存器负责指向这张表的起始位置。这样，原先的段寄存器存放的不再是一个简单的段基址，而是一个叫做 选择子 (Selector) 的东西，它相当于一个索引，将从 GDT 中找到对应的段基址，再加上偏移地址，通过这种方式来确定地址。

选择子的结构如下：

• Index 相当于段描述符的索引值，用此值在 GDT 中索引描述符。由于这部分一共有 13-bits，故可以索引 $2^{13} =8192$ 个段。
• TI (Table Indicator) 指示使用哪张描述符表，为 0 表示在 GDT 中索引段描述符，为 1 则在 LDT 中索引。
• RPL (Requested Privilege Level) 可以表示 0、1、2、3 四种特权级。

而下图就是 GDT 表项的结构了，其中灰色的那位是 L (Long Mode) 位，用于指示是 32-bit 还是 64-bit.

有关不同位的含义，可以参考 Global Descriptor Table，这里不再赘述。

通过上图你也看到了，像是段基址，段界限值，它们都被分割开来了，而不是连续存储的，这导致 CPU 还要对这些七零八落的数据进行重组，拼成一个完整的数据……还有访问内存中的段描述符，这些都需要时间，CPU 可等不起。因此，为了提高获取段信息的效率，将段信息缓存到了 段描述符缓存 (Segment Descriptor Cache)。每个段寄存器都有一个 hidden part，叫做段描述符缓存，它只有 CPU 可操作，CPU 每次将历经千辛万苦获取到的段信息整理成完整的、通顺、不蹩脚的形式后，存入段描述符缓存，以后每次访问相同的段时，就直接读取该段寄存器对应的的段描述符缓存。

TIP

虽然段描述符缓存是保护模式下的产物，但也可以用在实模式下。因为每次都将段基址左移 4 位也算一个不小的操作，所以也可以将移位后的结果缓存起来供下次使用。

至于这个缓存的失效时间，还真没个「准」。段描述符缓存不会自动刷新，只有当 CPU 重新加载段寄存器时才会更新。

比如这会刷新缓存：

1
mov ax, 0x10
2
mov ds, ax

这样则不会刷新段描述符缓存寄存器：

1
mov ax, ds
2
mov ds, ax

因此，除非手动重新加载段寄存器，否则 CPU 会一直使用旧的缓存，即使 GDT/LDT 已被修改。

此外，保护模式下寻址方式也得到了极大的扩展，灵活性得到了极大的提高。基址寄存器不再只能用 BX、BP，而是所有 32-bit 通用寄存器，变址寄存器也一样，不再只是 SI、DI，而是除 ESP 之外的所有 32-bit 通用寄存器。偏移量也从 16-bit 变成了 32-bit，并且，还可以对变址寄存器乘以一个比例因子，不过出于内存对齐的考虑，比例因子只能是 1、2、4、8。

还有一些杂七杂八的，比如指令扩展啦，运行模式反转啦之类的，不过我呀，是写不动了（改天也不一定会写的），有兴趣的自己看书查资料去吧～

最后说说进入保护模式需要做的三件事：

• 加载 GDT
• 打开 A20 Gate
• 将 CR0 的 PE (Protection Enable) 位置 1

这三个步骤可以不顺序，也不连续。至于实现，还是移步我的 GitHub 看实际代码好了，懒得写了……/逃