Linux从头学08：Linux 是如何保护内核代码的？从实模式到保护模式

Posted 2021-09-11 IOT物联网小镇

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux从头学08：Linux 是如何保护内核代码的？从实模式到保护模式相关的知识，希望对你有一定的参考价值。

作者：道哥，10+年的嵌入式开发老兵。

转载：欢迎转载文章，转载需注明出处。

文章目录

在之前的 7 篇文章中，我们一直学习的是最原始的 8086 处理器中的最底层的基本原理，重点是内存的寻址方式。

也就是：CPU 是如何通过[段地址:偏移地址]，来对内存进行寻址的。

不知道你是否发现了一个问题：

所有的程序都可以对内存中的任意位置的数据进行读取和修改，即使这个位置并不属于这个应用程序。

这是非常危险的，想一想那些心怀恶意的黑帽子黑客，如果他们想做一些坏事情，可以说是随心所欲！

面对这样的不安全行为，处理器一点办法都没有。

所以，Intel 从 80286 开始，就对增加了一个叫做保护模式的机制。

PS: 相应的，之前 8086 中的处理器执行模式就叫做“实模式”。

虽然 80286 没有形成一定的气候，但是它对后来的 80386 处理器提供了基础，让 386 获得了极大的成功。

这篇文章，我们就从 80386 处理器开始，聊一聊

保护模式究竟保护了谁？

底层是通过什么机制来实现保护模式的？

我们的学习目标，就是弄明白下面这张图：

从 16 位进入到 32 位

8086 的 16 位模式

在 8086 处理器中，所有的寄存器都是 16 位的。

也正因为如此，处理器为了能够得到 20 位的物理地址，需要把段寄存器的内容左移 4 位之后，再加上偏移寄存器的内容，才能得到一个 20 位的物理地址，最终访问最大 1MB 的内存空间。

例如：在访问代码段的时候，把 cs 寄存器左移 4 位，再加上 ip 寄存器，就得到 20 位的物理地址了;

20 位的地址，最大寻址范围就是 2 的 20 次方 = 1 MB 的空间;

还记得我们第 1 篇文章Linux 从头学 01：CPU 是如何执行一条指令的？中的寄存器示意图吗？

以上这些寄存器都是 16 位的，在这种模式下，对内存的访问只能分段进行。

而且每一个段的偏移地址，最大只能到 64 KB 的范围(2 的 16 次方)。

在访问代码段的时候，使用 cs:ip 寄存器;

在访问数据段的时候，使用 ds 寄存器;

在访问栈的时候，使用 ss:sp 寄存器;

80386 的 32 位模式

进入到 32 位的处理器之后，这些寄存器就扩展到 32 位了：

从寄存器的名称上可以出，在最前面增加了字母 E，表示 Extend 的意思。

这些 32 位的寄存器，低 16 位保持与 16 位处理器的兼容性，也就是可以使用 16 位的寄存器(例如：AX)，也可以使用 8 位的寄存器(例如：AH, AL)。

注意：高 16 位不可以独立使用。

下面这张图是 32 位处理器的另外 4 个通用寄存器(注意它们是不能按照 8 位寄存器来使用的)：

在 32 位的模式下，处理器中的地址线达到了 32 位，最大的内存空间可寻址能力达到 4 GB(2 的 32 次方)。

在 32 位处理器中，依然可以兼容 16 位的处理模式，此时依然使用 16 位的寄存器;

如果不兼容的话，就会失去很大的市场占有率;

是不是感觉到上面的寄存器示意图中漏掉了什么东西？

是的，图中没有展示出段寄存器(cs, ds, ss等等)。

这是因为在 32 位模式下，段寄存器依然是 16 位的长度，但是对其中内容的解释，发生了非常非常大的变化。

它们不再表示段的基地址，而是表示一个索引值以及其他信息。

通过这个索引值(或者叫索引号)，到一个表中去查找该段的真正基地址(有点类似于中断向量表的查找方式)：

有些书上把描述符称之为：段选择子;

也有一些书上把段寄存器中的值称之索引值，把段描述符在 GDT 中的偏移量称之为选择子;

不必纠结于称呼，明白其中的道理就可以了;

正是因为处理器有 32 根地址线，可寻址的范围已经非常大了(4 GB)，因此理论上它是不需要像 8086 中那样的寻址方式(段地址左移 4 位 + 偏移地址)。

但是由于 x86 处理器的基因，在 32 位模式下，依然要以段为单位来访问内存。

这里请大家不要绕晕了：刚才描述的段寄存器的内容时，仅仅是说明如何来找到一个段的基地址，也即是说：

对于 8086 来说，段寄存器中的内容左移 4 位之后，就是段的基地址;

对于 80386 来说，段寄存器中的内容是一个表的索引号，通过这个索引号，去查找表中相应位置中的内容，这个内容中就有段的基地址(如何查找，下文有描述);

找到了这个段的基地址之后，在访问内存的时候，仍然是按照段机制+偏移量的方式。

由于在 32 位处理器中，存储偏移地址的寄存器都是 32 位的，最大偏移地址可达 4 GB，所以，我们可以把段的基地址设置为 0x0000_0000：

这样的分段方式，称作“平坦模型”，也可以理解为没有分段。

看到这里，是否联想起之前的一篇文章中，我们曾经画过一张 Linux 操作系统中的分段模型:

现在是不是大概就明白了：为什么这 4 个段的基地址和段的长度，都是一样的？

从实模式进入到保护模式

如何进入保护模式

CPU 是如何判断：当前是执行的是实模式？还是保护模式？

在处理器内部，有一个寄存器 CR0。这个寄存器的 bit0 位的值，就决定了当前的工作模式：

bit0 = 0: 实模式;
bit1 = 1: 保护模式;

在处理器上电之后，默认状态下是工作在实模式。

当操作系统做好进入保护模式的一切准备工作之后，就把 CR0 寄存器的 bit0 位设置为 1，此后 CPU 就开始工作在保护模式。

也就是说：在 bit0 设置为 1 之前，CPU 都是按照实模式下的机制来进行寻址(段地址左移 4 位 + 偏移地址)；

当 bit0 设置为 1 之后，CPU 就按照保护模式下的机制来进行寻址(通过段寄存器中的索引号，到一个表中查找段的基地址，然后再加上偏移地址)。

GDT 全局描述符表

由于这张表中的每一个条目(Entry)，描述的是一个段的基本信息，包括：基地址、段的长度界限、安全级别等等，因此我们称之为全局描述符表(Global Descriper Table, GDT)。

之所以称之为全局的，是因为每一个应用程序还可以把段描述符信息，放在自己的一个私有的局部描述符表中(Local Descriper Table，LDT)，在以后的文章中一定会介绍到。

处理器规定：第一个描述符必须为空，主要是为了规避一些程序错误。

从上图中可以看出：GDT 中每一个条目的长度是 8 个字节，其中描述了一个段的具体信息，如下所示：

黄色部分：表示这个段在内存中的基地址。

绿色部分：表示这个段的最大长度是多少。

第一次看到这张图时，是不是心中有 2 个疑问：

为什么段的基地址不是用连续的 32 bit 位来表示?

段的界限怎么是 20 位的？20 位只能表示 1 MB 的范围啊?

第一个问题的答案是：历史原因(兼容性)。

第二问题的答案是：在每一个描述符中的标志位 G，对段的界限进行了进一步的粒度描述：

如果 G = 0: 表示段界限是以字节为单位，此时，段界限的最大表示范围就是 1 MB;

如果 G = 1：表示段界限是以 4 KB 为单位，此时，段界限的最大表示范围就是 4 GB( 1 MB 乘以 4KB);

为了完整性，我把所有标志位的含义都汇总如下，方便参考：

D/B (bit22)：用来决定数据段 or 栈段使用的偏移寄存器是 16 位还是 32 位。

L (bit21)：在 64 位系统中才会使用，暂时先忽略。

AVL (bit20)：处理器没有使用这一位内容，被操作系统可以利用这一位来做一些事情。

P (bit15)：表示这个段的内容，当前是否已经驻留在物理内存中。

在 Linux 系统中，每一个应用程序都拥有 4 GB(32位处理器) 的虚拟内存空间，而且一个系统中可以同时存在多个应用程序。

这些应用程序在虚拟内存中的代码段、数据段等等，最终都是要映射到物理内存中的。

但是物理内存的空间毕竟是有限的，当物理内存紧张的时候，操作系统就会把当前不在执行的那些段的内容，临时保存在硬盘上(此时，这个段描述符的 P 位就设置为 0)，这称之为换出。

当这个被换出的段需要执行时，处理器发现 P 位为 0，就知道段中的内容不在物理内存中，于是就在物理内存中找出一块空闲的空间，然后把硬盘中的内容复制到物理内存中，并且把 P 位设置为 1，这称之为换入。

DPL (bit14 ~ 13)：指定段的特权级别，处理器一共支持 4 个特权级别：0，1，2，3(特权级别最低)。

比如：操作系统的代码段的特权级别是 0，而一个应用程序在刚开始启动的时候，操作系统给它分配的特权级别是 3，那么这个应用程序就不能直接去转移到操作系统的代码段去执行。

在 Linux 操作系统中，只利用了 0 和 3 这两个特权级别。

S (bit12)：决定这个段的类型。

TYPE (bit11 ~ 8)：用来描述段的一些属性，例如：可读、可写、扩展方向、代码段的执行特性等等。

这里的依从属性不太好理解，它主要用于决定：从一个低特权级别的代码，是否可以进入另一个高特权级别的代码。

如果可以进入，那么当前任务的请求级别 RPL 是否发生改变(以后会讨论这个问题)。

另外，操作系统可以把 A 标志，加入到物理内存的换出换入计算策略中。

这样的话，就可以避免把最近频繁访问的物理内存换出，达到更好的系统性能。

GDTR 全局描述符表寄存器

还有一个问题需要处理：GDT 表本身也是数据，也是需要存放在内存中的。

那么: 它存放在内存中的什么位置呢？CPU 又怎么能知道这个起始位置呢？

在处理器的内部，有一个寄存器：GDTR (GDT Register)，其中存储了两个信息：

我们可以从上一篇文章Linux从头学07：【中断】那么重要，它的本质到底是什么？中，中断向量表的安装过程中进行类比：

程序代码把每一个中断的处理程序地址，放在中断向量表中的对应位置;

中断向量表的起始地址放在内存的 0 地址处;

也就是说：处理器是到固定的地址 0 处，查找中断向量表的，这是一个固定的地址。

而对于 GDT 表而言，它的起始地址不是固定的，而是可以放在内存中的任意位置。

只要把这个位置存放到寄存器 GDTR 中，处理器在需要的时候就可以通过 GDTR 来定位到 GDT 的起始地址。

其实，GDT 在上电刚开始的时候，也不能放在内存中的任意位置。

因为在进入保护模式之前，处理器还是工作在实模式，只能寻址 1 MB 的内存空间，因此，GDT 只能放在 1 MB 内的地址空间中。

在进入保护模式之后，能寻址更大的地址空间了，此时就可以重新把 GDT 放在更大的地址空间中了，然后把这个新的起始地址，存储到 GDTR 寄存器中。

从 GDTR 寄存器中的内容可以看出，它不仅存储了 GDT 的起始地址，而且还限制了 GDT 的长度。

这个长度一共是 16 位，最大值是 64 KB( 2 的 16 次方)，而一个段描述符信息是 8 B，那么 64 KB 的空间，最多一共可以存放 8192 个描述符。

这个数字，对于操作系统或者是一般的应用程序来说，是绰绰有余了。

段描述符的查找原理

在上面的段寄存器示意图中，我们只说明了段寄存器依然是 16 位的。

在保护模式下，对其中内容的解释，与实模式下是大不相同的。

我们以代码段寄存器 CS 为例：

RPL: 表示当前正在执行的这个代码段的请求特权级;

TI: 表示到哪一个表中去找这个段的描述信息：全局描述符表(GDT) or 局部描述符表(LDT)?

TI = 0 时，到 GDT 中找段描述符;
TI = 1 时，到 LDT 中找段描述符;

假设当前代码段寄存器 cs 的值为 0x0008，处理器按照保护模式的机制来解释其中的内容：

TI = 0，表示到 GDT 中查找段描述符;

RPL = 0，表示请求特权级别是 0;

描述符索引是 1，表示这个段描述符在 GDT 中的第 1 个条目中。由于每一个描述符占用 8 个字节，因此这个描述符的开始地址位于 GDT 中的偏移地址为 8 的位置(1 * 8 = 8);

找到了这个段描述符条目之后，就可以从中获取到这个代码段的具体信息了：

代码段的基地址在内存中什么位置;

代码段的最大长度是多少(在获取指令时，如果偏移地址超过这个长度，就引发异常);

代码段的特权级别是多少，当前是否驻留在物理内存中等等;

另外，从上文描述的 GDTR 寄存内容知道，它限制了 GDT 中最多一共可以存放 8192 个描述符。

我们再从代码段寄存器中，描述符索引字段所占据的 13 个 bit 位可以计算出，最多可以查找 8192 个段描述符。

2 的 13 次方 = 8192。

至此，处理器就在保护模式下，查找到了一个段的所有信息。

下面步骤就是：到这个段所在的内存空间中，执行其中的代码，或者读写其中的数据。

下一篇文章我们继续。。。

------ End ------

这篇文章主要描述了 80386 处理器中的保护模式下，段寄存器的使用，以及通过段描述符来查找段的具体信息。

从描述的内容来看，已经和我们的最终目标：Linux 操作系统中的执行方式，越来越接近了！

因为这些底层知识，都是 Linux 操作系统赖以运行的基础。

理解了这些基础内容，后面在学习 Linux 的具体模块时，就可以回过头来查一下它在处理器层面的底层支撑。

最后，如果这篇文章对您有一点帮助，请转发给身边的技术小伙伴，也是对我继续输出文章的最大鼓励和动力！

让我们一起出发，向着目标继续迈进！