一起学习x86/x64知识

最新推荐文章于 2024-01-20 12:42:56 发布

最新推荐文章于 2024-01-20 12:42:56 发布 · 234 阅读

文章标签：

#运维

本文深入探讨x86/x64体系结构中的细节问题，通过实验验证了官方手册中的一些描述与实际表现之间的差异，特别是在中断处理和优先级方面的差异。

在实际工作中接触到一些与x86/x64平台底层的问题时，往往是遇到不懂的就翻翻Intel或AMD提供的手册，这样掌握并不牢固，下次重遇问题时还要翻手册。现在让我们一起来系统地学习x86/x64体系知识，然后需要温故而知新。

实验的重要性

在学习过程中，我们以探索为目的，以实验为依托。要透彻地对一个知识点进行理解，显然经过测试实验的论证是最好的方法，也只有经过全方位的测试才是最为真实可靠的。Intel和AMD官方手册某些描述上存在着隐晦难懂的地方，甚至可能还会出现错误。因此测试实验起的作用是：验证真伪和去除疑惑。

下图是在Intel64软件开发者手册里截取到的一段有误的描述：

截图中描述的是INT指令在返回时的一部分处理流程：在IA-32e模式下（描述中包括了64位模式和compatibility模式）当operand size为32或16时，只会pop出32位或16位的CS，EIP以及EFLAGS值。然而实际上在64位模式下，处理器还会无条件pop出SS和ESP值并不依赖于operandsize的值。

这个描述与x64体系中的设计产生一些冲突（主要依据于AMD64手册的描述）。因此，在无法准确判断时，我们做出测试实验来验证，在64位模式下执行下面的代码：

mov WORD [rsp], 0

mov WORD [rsp + 2], KERNEL_CS

mov WORD [rsp + 4], 46

mov WORD [rsp + 6], 08F0h

mov WORD [rsp + 8], 0A0h

db 66h

iret

这段代码执行16位的中断返回，在栈中压入的是16位的值，实验的结果是：

这是运行在bochs上的测试结果，RSP和SS值没有改变，没有pop出SS与SP值，这是bochs按照Intel64手册上所描述的流程进行模拟了。

在vmware和真实机器上执行显示出SS值为0A0h，RSP值为08F0h，处理器已经从栈中POP出SS与SP值。

然这个实验可以写得更好些更清晰些，显然从这个实验测试里知道Intel64手册中的这一段描述与事实不符。这里阐述了实验作用之一：就是验证真伪。

下面一段话是关于中断优先级别的描述：

“Each interrupt vector is an 8-bitvalue. The interrupt-priority class is the value of bits 7:4 of theinterrupt vector. The lowest interrupt-priority class is 1 and the highest is15; interrupts with vectors in the range 0–15 (with interrupt-priority class 0)are illegal and are never delivered. Because vectors 0–31 are reserved fordedicated uses by

the Intel 64 and IA-32 architectures, software should configure interruptvectors to use interrupt-priority classes in the range 2–15.

Each interrupt-priority class encompasses 16 vectors. The relativepriority of interrupts within an interrupt-priority class is determined by thevalue of bits 3:0 of the vector number. The higher the value of those bits, thehigher the priority within that interrupt-priority class. Thus, each interruptvector comprises two parts, with the high 4 bits indicating itsinterrupt-priority class and the low 4 bits indicating its ranking within theinterrupt-priority class.”

这段话描述8位的中断vector被分为两部分用来管理优先级，高4位是priorityclass，低4位是priority ranking。我们可以看作：高4位管理等级，低4位是等级内的排名。vector值大优先级别就高。

然而这里的描述会让我们产生困惑：同一个class内的ranking是否越大优先级别越高，实际上不是，处理器响应中断请求是按vector[7:4]值来仲裁：只有priority class大的才能响应。

上图所显示的是另一个测试实验，当我们对TPR（Task Priority Register）设置的值为0x32时，它的中断门坎的priority class值为3（第3级），同时PPR（Processor Priority Register）也被置为0x32，PPR的值受TPR与ISR影响。只有满足下列条件时中断请求才能被响应：

vector[7:4] > PPR[7:4]

因此：vector为0x33的中断请求发生时，将会被阻塞得不到响应的，只有vector的priority class值大于3时才会响应。

然而，Intel64手册里描述的并不清晰，我们只能通过实验来测试和验证，去除我们的困惑，这是实验的第二个作用。

构造实验平台

我们可以想象到：由于OS的限制，大多数实验是并不适合在现有的OS平台里进行测试。因此我们需要选择要祼机上进行测试。

可以选择的运行环境有真实机器，bochs模拟器或者vmware虚拟机。那么我们可以选择的介质是U盘，硬盘映像文件或者软盘映像文件，并需要编写自己的boot程序来引导测试实验。根据不同的介质软件不同的格式：U盘和硬盘映像文件使用FAT32格式，软件映像文件可以直接将boot代码写入MBR中即可。

上面是启动boot程序的流程，FAT32文件格式中，我们的boot程序写入63号扇区（从0开始），BIOS将boot程序读入7C00h位置后，继续加载我们实验的后续模式。

以U盘和硬盘映像文件使用的FAT32文件格式为例，下面的映像文件组织：

我们实验中常用的模块是boot模块，setup模块，lib16模块，protected模块，lib32模块以及long模块。lib16与lib32模块是库代码，protected模块是32位保护模式执行代码，long模块是64位long模块执行代码，而boot模块引导它们，setup模块切入保护模式。

规定了这些模块在映像文件中的存放位置后，需要将这些模块代码写入映像文件中，可以使用最原始的方法，即：手工使用Hex类型软件合并写入。这种方法实在是太麻烦了。

这里使用自己编写的合并工具merge，根据它的配置文件批量写入到映像文件中，下面是配置文件的示例：

# 输入文件, 输入文件 offset, 输出文件, 输出文件 offset, 写入 block 数( 1 block = 512bytes)

#**** 每一项用逗号分隔 ****

#example:

#模块名 offset 输出文件名 offset count(1count = 512 bytes）

#-------------------------------------------------

#boot, 0, demo.img, 0, 1

#setup, 0, demo.img, 1, 2

#init, 0, demo.img, 3, 5

# 意思是：

#boot 模块从 block 0 开始写入 demo.img 写入位置为 block 0, 写入 1 个 block