长模式

可以在汇编源码 arch/x86/boot/compressed/head_64.S 中找到 32 位入口点的定义

__HEAD
.code32
ENTRY(startup_32)
....
....
....
ENDPROC(startup_32)

首先，为什么目录名叫做 被压缩的 compressed ？实际上 bzimage 是由 vmlinux + 头文件 + 内核启动代码 被 gzip 压缩之后获得的

在前几个章节已经看到了启动内核的代码

head_64.S 的主要目的就是做好进入长模式的准备之后进入长模式，进入以后再解压内核

接下来将会看到直到内核解压缩之前的所有步骤

在 arch/x86/boot/compressed 目录下有两个文件：

• head_32.S
• head_64.S

这里只和 x86_64 有关，所以只会关注 head_64.S， head_32.S 没有被用到

先看一下 arch/x86/boot/compressed/Makefile 。可以看到以下目标：

vmlinux-objs-y := $(obj)/vmlinux.lds $(obj)/head_$(BITS).o $(obj)/misc.o \
               $(obj)/string.o $(obj)/cmdline.o \
               $(obj)/piggy.o $(obj)/cpuflags.o

注意 \((obj)/head_\)(BITS).o 。这意味着将会选择基于 $(BITS) 所设置的文件执行链接操作，即 head_32.o 或者 head_64.o 。$(BITS) 在 arch/x86/Makefile 之中根据 .config 文件另外定义：

ifeq ($(CONFIG_X86_32),y)
BITS := 32
...
...
else
    BITS := 64
    ...
    ...
    endif

现在知道从哪里开始了，那就来吧

首先看到了在 startup_32 之前的特殊段属性定义：

__HEAD
.code32
ENTRY(startup_32)

这个 __HEAD 是一个定义在头文件 include/linux/init.h 中的宏，展开后就是下面这个段的定义：

#define __HEAD          .section        ".head.text","ax"

其拥有 .head.text 的命名和 ax 标记。这些标记说明这个段是 可执行的，或者换种说法，包含了代码。可以在 arch/x86/boot/compressed/vmlinux.lds.S 这个链接脚本里找到这个段的定义：

SECTIONS
{
    . = 0;
    .head.text : {
        _head = . ;
        HEAD_TEXT
        _ehead = . ;
    }

简单来说，这个 . 符号是一个 链接器 的特殊变量 位置计数器 。其被赋值为 相对于该段 的 偏移

在这里，将位置计数器赋值为0，这意味着代码被链接到内存的 0 偏移处

如果不熟悉 GNU LD 这个链接脚本语言的语法，可以在 https://sourceware.org/binutils/docs/ld/Scripts.html#Scripts 中找到更多信息

此外，可以从注释里找到更多信息：

Be careful parts of head_64.S assume startup_32 is at address 0.

要小心， head_64.S 中一些部分假设 startup_32 位于地址 0

在 startup_32 函数的开始，可以看到 cld 指令将 标志寄存器的 DF 方向标志位 清空。当方向标志被清空，所有的串操作指令像 stos ， scas 等等将会 增加 索引寄存器 esi 或者 edi 的值

需要清空方向标志是因为接下来会使用汇编的串操作指令来做为页表腾出空间等工作

在清空 DF 标志后，下一步就是从内核加载头中的 loadflags 字段来检查 KEEP_SEGMENTS 标志

在本书的最初一节，其实已经看到过 loadflags

在那里检查了 CAN_USE_HEAP 标记以使用堆

现在需要检查 KEEP_SEGMENTS 标记。这些标记在 linux 的 引导协议 文档中有描述：

Bit 6 (write): KEEP_SEGMENTS
  Protocol: 2.07+
  - If 0, reload the segment registers in the 32bit entry point.
  - If 1, do not reload the segment registers in the 32bit entry point.
    Assume that %cs %ds %ss %es are all set to flat segments with
	a base of 0 (or the equivalent for their environment).


第 6 位 (写): KEEP_SEGMENTS
  协议版本: 2.07+
  - 为0，在32位入口点重载段寄存器
  - 为1，不在32位入口点重载段寄存器。假设 %cs %ds %ss %es 都被设到基地址为0的普通段中（或者在他们的环境中等价的位置）

所以，如果 KEEP_SEGMENTS 位在 loadflags 中没有被设置，需要重置 ds , ss 和 es 段寄存器到一个基地址为 0 的普通段中。如下：

testb $(1 << 6), BP_loadflags(%esi)
jnz 1f

cli
movl    $(__BOOT_DS), %eax
movl    %eax, %ds
movl    %eax, %es
movl    %eax, %ss

记住 __BOOT_DS 是 0x18 （位于 全局描述符表 中 数据段 的索引）。如果设置了 KEEP_SEGMENTS ，就跳转到最近的 1f 标签，或者当没有 1f 标签，则用 __BOOT_DS 更新段寄存器

这非常简单，但这是一个有趣的操作

如果已经读了前一章节，或许还记得在 arch/x86/boot/pmjump.S 中切换到保护模式的时候已经更新了这些段寄存器

那么为什么还要去关心这些段寄存器的值呢？

答案很简单，Linux 内核也有32位的引导协议，如果一个引导程序之前使用32位协议引导内核，那么在 startup_32 之前的代码就会被忽略

在这种情况下 startup_32 将会变成引导程序之后的第一个入口点，不保证段寄存器会不会处于未知状态

下一步就是计算代码的加载和编译运行之间的位置偏差了

记住 setup.ld.S 包含了以下定义：在 .head.text 段的开始 . = 0

这意味着这一段代码被编译成从 0 地址运行

可以在 objdump 工具的输出中看到：

arch/x86/boot/compressed/vmlinux:     file format elf64-x86-64


Disassembly of section .head.text:

0000000000000000 <startup_32>:
0:   fc                      cld
1:   f6 86 11 02 00 00 40    testb  $0x40,0x211(%rsi)

objdump 工具显示 startup_32 的地址是 0

但实际上并不是。现在需要知道实际上在哪里

在长模式下，这非常简单，因为其支持 rip 相对寻址

但是当前处于保护模式下。将会使用一个常用的方法来确定 startup_32 的地址。需要定义一个标签并且跳转到它，然后把栈顶抛出到一个寄存器中：

        call label
label: pop %reg

在这之后，那个寄存器将会包含标签的地址，Linux 内核中类似的寻找 startup_32 地址的代码：

        leal    (BP_scratch+4)(%esi), %esp // 把 scratch 的地址加 4 存入 esp 寄存器
        call    1f // 跳转到1f 
1:  popl        %ebp // 把1f标签的地址放入ebf 
        subl    $1b, %ebp 

esi 寄存器包含了 boot_params 结构的地址，这个结构在切换到保护模式之前已经被填充了。bootparams 这个结构体包含了一个特殊的字段 scratch ，其偏移量为 0x1e4 。这个 4 字节的区域将会成为 call 指令 的 临时栈

之所以在 BP_scratch 基础上加 4 是因为，如之前所说的，这将成为一个临时的栈

而在 x86_64 架构下，栈是自顶向下生长的。所以栈指针就会指向栈顶

接下来就可以看到上面描述的过程。跳转到 1f 标签并且把该标签的地址放入 ebp 寄存器

因为在执行 call 指令之后我们把返回地址放到了栈顶

那么，既然已经拥有 1f 标签的地址，也能够很容易得到 startup_32 的地址

只需要把 从栈里得到的地址 减去 标签的地址 ：

startup_32 (0x0)     +-----------------------+
                     |                       |
                     |                       |
                     |                       |
                     |                       |
                     |                       |
                     |                       |
                     |                       |
                     |                       |
1f (0x0 + 1f offset) +-----------------------+ %ebp - 实际物理地址
                     |                       |
                     |                       |
                     +-----------------------+

startup_32 被链接为在 0x0 地址运行，这意味着 1f 的地址 为 0x0 + 1f 的偏移量 。实际上偏移量大概是 0x22 字节。 ebp 寄存器 包含了 1f 标签的实际物理地址 。所以如果从 ebp 中减去 1f ，就会得到 startup_32 的实际物理地址。Linux 内核的引导协议描述了保护模式下的内核基地址是 0x100000

可以用 gdb 来验证。启动调试器并且在 1f 的地址 0x100022 添加断点。如果这是正确的，将会看到在 ebp 寄存器中值为 0x100022 ：

$ gdb
(gdb)$ target remote :1234
Remote debugging using :1234
0x0000fff0 in ?? ()
(gdb)$ br *0x100022
Breakpoint 1 at 0x100022
(gdb)$ c
Continuing.

Breakpoint 1, 0x00100022 in ?? ()
(gdb)$ i r
eax            0x18     0x18
ecx            0x0      0x0
edx            0x0      0x0
ebx            0x0      0x0
esp            0x144a8  0x144a8
ebp            0x100021 0x100021
esi            0x142c0  0x142c0
edi            0x0      0x0
eip            0x100022 0x100022
eflags         0x46     [ PF ZF ]
cs             0x10     0x10
ss             0x18     0x18
ds             0x18     0x18
es             0x18     0x18
fs             0x18     0x18
gs             0x18     0x18

如果执行下一条指令 subl $1b, %ebp ，将会看到：

nexti
...
ebp            0x100000 0x100000
...

好了，那是对的。startup_32 的地址是 0x100000

知道了 startup_32 的地址之后，可以开始准备切换到 长模式了

下一个目标是建立栈并且确认 CPU 对长模式和 SSE 的支持

如果不知道 startup_32 标签的地址，就无法建立栈

可以把栈看作是一个数组，并且栈指针寄存器 esp 必须指向 数组的底部 。当然可以在自己的代码里定义一个数组，但是需要知道其真实地址来正确配置栈指针。看一下代码：

movl    $boot_stack_end, %eax // eax 寄存器将包含 boot_stack_end 链接后的地址 (0x0 + boot_stack_end) 
addl    %ebp, %eax // ebp 寄存器里是 startup_32 的实际物理地址
movl    %eax, %esp // esp 指向 boot_stack_end的实际物理地址

boots_stack_end 标签被定义在同一个汇编文件 head_64.S 中，位于 .bss 段：

        .bss
        .balign 4
boot_heap:
        .fill BOOT_HEAP_SIZE, 1, 0
boot_stack:
        .fill BOOT_STACK_SIZE, 1, 0
boot_stack_end:

1. 首先，把 boot_stack_end 放到 eax 寄存器 中。那么 eax 寄存器将包含 boot_stack_end 链接后的地址或者说 0x0 + boot_stack_end

2. 为了得到 boot_stack_end 的实际地址，需要加上 startup_32 的实际地址

   回忆一下，前面找到了这个地址并且把它存到了 ebp 寄存器中
   

3. 最后，eax 寄存器将会包含 boot_stack_end 的实际地址，只需要将其放到栈指针上

到这里已经建立了栈

下一步是 CPU 的确认。既然将要切换到 长模式 ，需要检查 CPU 是否支持 长模式 和 SSE 。跳转到 verify_cpu 函数之后执行：

call    verify_cpu
testl   %eax, %eax
jnz     no_longmode

这个函数定义在 arch/x86/kernel/verify_cpu.S 中，包含了几个对 cpuid 指令的调用。该指令用于 获取 处理器的信息

这里，它检查了对 长模式 和 SSE 的支持

通过 eax 寄存器返回 0 表示成功，1 表示 失败

• 如果 eax 的值不是 0 ，就跳转到 no_longmode 标签

  no_longmode:
  1:
          hlt
          jmp     1b
  

  • 用 hlt 指令停止 CPU ，期间不会发生硬件中断
• 如果 eax 的值为0，万事大吉，可以继续

下一步是在必要的时候计算解压缩之后的地址

首先，需要知道 内核重定位 的意义

我们已经知道 Linux 内核的32位入口点地址位于 0x100000，但是那是一个32位的入口

默认的内核基地址由内核配置项 CONFIG_PHYSICAL_START 的值所确定，其默认值为 0x1000000 或 16 MB

主要问题是如果内核崩溃了，内核开发者需要一个配置于不同地址加载的 救援内核 来进行 kdump 。Linux 内核提供了特殊的配置选项以解决此问题 CONFIG_RELOCATABLE 。可以在内核文档中找到：

This builds a kernel image that retains relocation information
so it can be loaded someplace besides the default 1MB.

Note: If CONFIG_RELOCATABLE=y, then the kernel runs from the address
it has been loaded at and the compile time physical address
(CONFIG_PHYSICAL_START) is used as the minimum location.

这建立了一个保留了重定向信息的内核镜像，这样就可以在默认的 1MB 位置之外加载了。

注意：如果 CONFIG_RELOCATABLE=y， 那么 内核将会从其被加载的位置运行，编译时的物理地址 (CONFIG_PHYSICAL_START) 将会被作为最低地址位置的限制

简单来说，这意味着相同配置下的 Linux 内核可以从不同地址被启动。这是通过将程序以 位置无关代码 的形式编译来达到的。如果参考 arch/x86/Makefile 将会看到解压器的确是用 -fPIC 标记编译的：

KBUILD_CFLAGS += -fno-strict-aliasing -fPIC

当使用位置无关代码时，一段代码的地址是由一个 控制地址 加上 程序计数器 计算得到的

可以从任意一个地址加载使用这种方式寻址的代码。这就是为什么我们需要获得 startup_32 的实际地址

现在回到 Linux 内核代码。目前的目标是计算出内核解压的地址

这个地址的计算取决于内核配置项 CONFIG_RELOCATABLE ：

#ifdef CONFIG_RELOCATABLE
        movl    %ebp, %ebx // ebp 寄存器的值就是 startup_32 标签的物理地址
        movl    BP_kernel_alignment(%esi), %eax
        decl    %eax
        addl    %eax, %ebx
        notl    %eax
        andl    %eax, %ebx // 对齐到 2M 的整数倍
        cmpl    $LOAD_PHYSICAL_ADDR, %ebx // 和 LOAD_PHYSICAL_ADDR 的值
        jge     1f
#endif
        // 加上偏移来获得解压内核镜像的地址
        movl    $LOAD_PHYSICAL_ADDR, %ebx
1:
        addl    $z_extract_offset, %ebx // 直接加上 z_extract_offset

如果在内核配置中 CONFIG_RELOCATABLE 内核配置项开启：

1. 就把 ebp 寄存器放到 ebx 寄存器中
2. 对齐到 2M 的整数倍
3. 和 LOAD_PHYSICAL_ADDR 的值比较

   • LOAD_PHYSICAL_ADDR 宏定义在头文件 arch/x86/include/asm/boot.h 中：

     #define LOAD_PHYSICAL_ADDR ((CONFIG_PHYSICAL_START \
                                     + (CONFIG_PHYSICAL_ALIGN - 1)) \
                                     & ~(CONFIG_PHYSICAL_ALIGN - 1))
     

     该宏只是展开成对齐的 CONFIG_PHYSICAL_ALIGN 值，其表示了内核加载位置的物理地址
     

4. 给 startup_32 加上 偏移 来获得 解压内核镜像的地址 ：
   • 如果 CONFIG_RELOCATABLE 选项在内核配置时没有开启，就直接将默认的地址加上 z_extract_offset

在前面的操作之后，ebp 包含了加载时的地址，ebx 被设为内核解压缩的目标地址

在得到了重定位内核镜像的基地址之后，开始做切换到64位模式之前的最后准备

首先，需要更新全局描述符表：

leal    gdt(%ebp), %eax // 把 ebp 寄存器加上 gdt 的偏移存到 eax 寄存器
movl    %eax, gdt+2(%ebp) // 把这个地址放到 ebp 加上 gdt+2 偏移的位置上
lgdt    gdt(%ebp) // 用 lgdt 指令载入 全局描述符表

为了理解这个神奇的 gdt + 2偏移量，需要关注 全局描述符表 的定义。可以在同一个源文件中找到其定义：

        .data
gdt:
        .word   gdt_end - gdt // 全局描述符表的大小 (16位) 
        .long   gdt // 全局描述符表的基址 （32位）
        .word   0
        .quad   0x0000000000000000      /* NULL descriptor */
        .quad   0x00af9a000000ffff      /* __KERNEL_CS */
        .quad   0x00cf92000000ffff      /* __KERNEL_DS */
        .quad   0x0080890000000000      /* TS descriptor */
        .quad   0x0000000000000000      /* TS continued */
gdt_end:

全局描述符表位于 .data 段，并且包含了5个描述符： null 、 内核代码段 、 内核数据段 和其他两个 任务描述符

已经在上一章节载入了 全局描述符表 ，现在要做的也差不多

需要把描述符改为 CS.L = 1, CS.D = 0 从而在 64 位模式下执行

而gdt 的定义：

• 两个字节：gdt_end - gdt ，代表了 gdt 表的最后一个字节，或者说表的范围
• 4个字节包含了 gdt 的基地址

全局描述符表 保存在 48位 GDTR寄存器 中，由两个部分组成：

• 全局描述符表的大小 (16位）
• 全局描述符表的基址 (32位)

所以，当把 gdt 的地址放到 eax 寄存器，然后存到 .long gdt 和 gdt+2。最后用 lgdt 指令 载入 到GDPR寄存器 中。

这样全局描述符表就更新完毕了

接下来必须启用 PAE 模式。方法是将 cr4 寄存器 的值传入 eax ，将 第5位 置 1 ，然后再 写回 cr4

movl    %cr4, %eax // 载入 cr4 寄存器
orl     $X86_CR4_PAE, %eax // 第5位置为1
movl    %eax, %cr4 // 写回 cr4 寄存器

现在已经接近完成进入64位模式前的所有准备工作了

最后一步是建立页表，但是在此之前，先介绍一些关于长模式的知识

长模式是 x86_64 系列处理器的原生模式。首先看一看 x86_64 和 x86 的一些区别，64位 模式提供了一些新特性，比如：

• 从 r8 到 r15 8个新的通用寄存器，并且所有通用寄存器都是 64位 的
• 64位指令指针: RIP
• 新的操作模式：长模式
• 64位地址和操作数
• RIP 相对寻址

长模式是一个传统保护模式的扩展，其由两个子模式构成：

1. 64位模式
2. 兼容模式

为了切换到 64位 模式，需要完成以下操作：

• 启用 PAE
• 建立 页表 并且将顶级页表的地址放入 cr3 寄存器
• 启用 EFER.LME
• 启用 分页