1. 实模式下的中断机制
   • 中断向量表（IVT）
   • 改变中断向量表地址
   • 设置自己的中断服务例程
2. 保护模式下的中断机制
   • 查找 interrupt handler 入口
   • IDT 表中 descriptor 类型的检查
   • 使用 16-bit gate descriptor
   • IDT 表的 limit 检查
   • 请求访问 interrupt handler 时的权限检查
     • gate 的权限设置
     • interrupt handler 的 code segment 权限设置
   • 使用 interrupt gate
   • 使用 trap gate
   • 使用 task gate
     • 任务切换的情形

1. 实模式下的中断机制

x86 processor 在加电后被初始化为 real mode 也称为 real-address mode，关于实模式请详见文章：http://www.mouseos.com/arch/001.html

processor 执行的第一条指针在 0xFFFFFFF0 处，这个地址经过 North Bridge（北桥）和 South ridge（南桥）芯片配合解码，最终会访问到固化的 ROM 块，同时，经过别名机制映射在地址空间低端，实际上等于 ROM 被映射到地址空间最高端和低端位置。

此时在系统的内存里其实并不存在 BIOS 代码，ROM BIOS 的一部分职责是负责安装 BIOS 代码进入系统内存。

典型是这条指令就是 0xFFFFFFF0 处的 ROM BIOS 指令，执行后它将跳到 0x000FE05B 处，这条指令的作用很大：

• 更新 CS.base 使 processor 变成纯正的 real mode
• 跳转到低端内存，使之进入 1M 低端区域

前面说过，此时内存中也不存在 BIOS，也就是说 IVT（中断向量表）也是不存在的，中断系统此时是不可用的，那么由 ROM BIOS 设置 IVT 。

1.1 中断向量表（IVT）

IDTR.base 被初始化为 0，ROM BIOS 将不会对 IDTR.base 进行更改，因此如果实模式 OS 不更改 IDTR.base 的值，这意味着 IVT 在 0 的位置上，典型的如： DOS 操作系统。

在保护模式下 IDTR.base 将向不再是中断向量表，而是中断描述符表。不再称为 IVT 而是 IDT。那是因为：

• 在实模式下，DITR.base 指向的表格项直接给出中断服务例程（Interrupt Service Routine）的入口地址。
• 在保护模式下，并不直接给出入口地址，而是门描述符（Interrupt/Trap/Task gate），从这些门描述符间接取得中断服务例程入口。

在 x86/x64 体系中允许有 256 个中断存在，中断号从 0x00 - 0xff，共 256 个中断，如图：

上面这个图是实模式下的 IVT 表，每个向量占据 4 个字节，中断服务例程入口是以 segment:offset 形式提供的，offset 在低端，segment 在高端，整个 IVT 表从地址 0x0 - 0x3FF，占据了 1024 个字节，即 1K bytes

1.2 改变中断向量表地址

事实上，我们完全可以在实模式下更改 IVT 的地址，下面的代码作为示例：

在 vmware 上这段代码的执行结果如图：

这段代码在实模式下将 IVT 表复制到 0x8000 位置上，然后将 IVT 地址设为 0x8000 上，这样完全可以正常工作。正如代码上看到的，我做：

1. 使用 sidt 指令取得 IDTR 寄存器的值，即 IVT 的 limit 和 base 值，保存在 old_IVT 里
2. 设置 new_IVT 值，limit 等于 old_IVT 的 limit，base 设为 0x8000
3. 将 IVT 表复制到 0x8000 处
4. 使用 lidt 指令加载 IDTR 寄存器，即设 IVT 表在 0x8000 处

1.3 设置自己的中断服务例程

在中断向量表里还有许多空 vector 是未使用的，我们可以在这些空白的向量里设置自己的中断服务例程，典型的如： DOS 操作系统中使用了 0x21 号向量作为 DOS 提供给用户的系统调用！

在这里我将展示，使用 0x40 向量作为自己的中断服务例程向量，我所需要做的是：

1. 写一个自己的中断服务例程，在本例中的 my_isr
2. 设置向量 0x40 的 segment 和 offset 值
3. 调用 int 0x40 进行测试

中断服务例程 my_isr 很简单，仅仅是打印信息：

接下来设置 vector 0x40 的 segment 和 offset：

记住 segment 在高位，offset 在低位，这个 segment 是我们当前的 CS，offset 是我们的 ISR 地址，直接写入 IVT 表中就可以了

现在我们可以测试了：

结果如下：

我们的 ISR 能正常工作了，我提供了完整的示例源码和磁盘映像下载：interrupt_demo

2. 保护模式下的中断机制

引入保护模式后，情形变得复杂多了，实施了权限控制机制，为了支持权限的控制增添了几个重要的数据结构，下面是与中断相关的结构：

• gate descriptor（门描述符）：用于描述和控制 Interrupt Service Routine 的访问，中断可使用的 gate 包括：
  • Interrupt-gate descriptor（中断门描述符）
  • Trap-gate descriptor（陷井门描述符）
  • Task-gate descriptor（任务门描述符）-- 在 64 位模式下无效
• interrupt descriptor table（中断描述符表）：用于存在 gate descriptor 的表格

在 32 位保护模式下，每个 gate descriptor 是 8 bytes 宽，在 64 位模式下 gate descriptor 被扩充为 16 bytes, 同时 64 位模式下不存在 task gate descriptor，因此在 64 位下的 IDT 只允许存放 interrupt/trap gate descriptor。

当我们执行调用中断时，processor 会在 IDT 表中寻找相应的 descriptor，并通过了权限检查转入相应的 interrupt service routine（大多数时候被称为 interrupt handler），在中断体系里分为两种引发方式：

• 由硬件引发请求
• 由软件执行调用

然而软件上发起的中断调用还可分为：

• 引发 exception（异常） 执行 interrupt handler
• 软件请求执行 system service（系统服务），而执行 interrupt handler

硬件引发的中断请求还可分为：

• maskable interrupt（可屏蔽中断）
• non-maskable interrupt（不可屏蔽中断）

无论何种方式，进入 interrupt handler 的途径都是一样的。

2.1 查找 interrupt handler 入口

在发生中断时，processor 在 IDTR.base 里可以获取 IDT 的地址，根据中断号在 IDT 表里读取 descriptor，descriptor 的职责是给出 interrupt handler 的入口地址，processor 会检查中断号（vector）是否超越 IDT 的 limit 值。

上图是 interrupt handler 的定位查找图。在 32 位模式下的过程是：

1. 从 IDTR.base 得到 IDT 表地址
2. 从 IDTR.base + vector * 8（每个 descriptor 为 8 bytes）处读取 8 bytes 宽的 escriptor
3. 对 descriptor 进行分析检查，包括：
   • descriptor 类型的检查
   • IDT limit 的检查
   • 访问权限的检查
4. 从 gate descriptor 里读取 selector
5. 判断 code segment descriptor 是存放在 GDT 表还是 LDT 表
6. 使用 selector 从 descriptor table 读取 code segment descriptor，当然这里也要经过对 code segment descriptor 的检查
   • descriptor 类型检查
   • GDT limit 检查
   • 访问权限的检查
7. 从 code segment descriptor 中读取 code segment base 值
8. 从 gate descriptor 里读取 interrupt handler 的 offset 值
9. 得取 interrupt handler 的入口地址：base + offset，转入执行 interrupt handler

它的逻辑用 C 描述，类似下面：

上面的 C 代码显示了 processor 定位 interrupt handler 的逻辑过程，为了清楚展示这个过程，这里省略了各种的检查机制！

2.2 IDT 表中 descriptor 类型的检查

processor 会对 IDT 表中的 descriptor 类型进行检查，这个检查发生在：

在 IDT 中的 descriptor 类型要属于：

• S = 0：属于 system 类 descriptor
• descriptor 的 type 域应属于：
  • 1110：32-bit interrupt gate
  • 1111：32-bit trap gate
  • 0101：task gate
  • 0110：16-bit interrupt gate
  • 0111：16-bit trap gate

非上述所说的类型，都将会产生 #GP 异常。当 descriptor 的 S 标志为 1 时，表示这是个 user 的 descriptor，它们是：code/data segment descriptor。可以看到在 32 位保护模式下 IDT 允许存在 interrupt/trap gate 以及 task gate

2.3 使用 16-bit gate descriptor

在 32 位保护模式下 interrupt handler 也能使用 16-bit gate descriptor，包括：

• 16-bit interrupt gate
• 16-bit trap gate

这是一个比较特别的现象，假如使用 16-bit gate 来构建中断调用机制，实际上等于 interrupt handler 会从 32-bit 模式切换到 16-bit 模式执行。只要构建环境要素正确这样切换执行当然是没问题的。

这个执行环境要素需要注意的是：当使用 16-bit gate 时，也要相应使用 16-bit code segment descriptor。也就是在 gate descriptor 中的 selector 要使用 16-bit code segment selector。下面我写了个使用 16-bit gate 构建 interrupt 调用的例子：

上面这段代码将 vector 3 设置为使用 16-bit interrupt gate，并且使用了 16-bit selector

下面是我的 interrupt handler 代码：

这个 interrupt handler 很简单，只是打印一条信息而已，值得注意的是，这里需要使用 bits 16 来指示编译为 16 位代码。

那么这样我们就可以使用 int3 指令来调用这个 16-bit 的 interrupt handler，执行结果如图：

完整的源代码和软盘映像下载：interrupt_demo1.rar

2.4 IDT 表的 limit 检查

在 IDT 表中查找索引 gate descriptor 时，processor 也会对 IDT 表的 limit 进行检查，这个检查的逻辑是：

我们看看下面这个图：

当我们设:

• IDTR.base = 0x10000
• IDTR.limit = 0x1f

那么 IDT 表的有效地址范围是：0x10000 - 0x1001f，也就是：IDTR.base + IDTR.limit 这表示：

• vector 0：0x10000 - 0x10007
• vector 1：0x10008 - 0x1000f
• vector 2: 0x10010 - 0x10017
• vector 3: 0x10018 - 0x1001f

上面是这 4 个 vector 的有效范围，因此：当设 IDTR.limit = 0x1e 时，如果访问 vector 3 时（调用中断3）processor 检测到访问 IDT 越界而出错！

因此：访问的 vector 地址在 IDTR.base 到 IDTR.base + IDTR.limit（含）之外，将会产生 #GP 异常。

2.5 请求访问 interrupt handler 时的权限检查

访问权限的检查是 x86/x64 体系中保护措施中非常重要的一环，它控制着访问者是否有权限进行访问，在访问 interrupt handler 过程权限控制中涉及 3 个权限类别：

• CPL：当前 processor 所处的权限级别
• DPLg：代表 DPL of gate，也就是 IDT 中 gate descriptor 所要求的访问权限级别
• DPLs：代表 DPL of code segment，也就是 interrupt handler 的目标 code segment 所要求的访问权限级别

CPL 权限级别代表着访问者的权限，也就是说当前正在执行代码的权限，要理解权限控制的逻辑，你需要明白下面两点：

1. 要调用 interrupt handler 那么首先你必须要有权限去访问 IDT 表中的 gate，这表示：CPL 的权限必须不低于 DPLg (gate 所要求的权限），这样你才有权限去访问 gate
2. interrupt handler 会在高权限级别里执行，也就是说 interrupt handler 会在特权级别里运行。这表示：interrupt handler 里的权限至少不低于访问者的权限

在调用 interrupt handler 中并不使用 selector 来访问 gate 而是使用使用 vector 来访问 gate，因此中断权限控制中并不使用 RPL 权限类别，我们可以得知中断访问权限控制的要素：

• CPL <= DPLg
• CPL >= DPLs

需同时满足上面的两个式子，在比较表达式中数字高的权限低，数字低的权限高！用 C 描述为：

2.5.1 gate 的权限设置

对于 gate 的权设置，我们应考虑 interrupt handler 调用上的两个原则：

• interrupt handler 开放给用户调用
• interrupt handler 在系统内部使用

由这两个原则产生了 gate 权根设置的两个设计方案：

• gate 的权限设置为 3 级：这样可以给用户代码有足够的权限去访问 gate
• gate 的权限设置为 0 级：只允许内核代码访问，用户无权通过这个 gate 去访问 interrupt handler

这是现代操作系统典型的 gate 权限设置思路，绝大部分的 gate 都设置为高权限，仅有小部分允许用户访问。很明显：系统服务例程的调用入口应该设置为 3 级，以供用户调用。

下面是很典型的设计：

• #BP 异常：BreakPoint（断点）异常的 gate 应该设置为 3 级，使得用户程序能够使用断点调试程序。
• 系统调用：系统调用是 OS 提供给用户访问 OS 服务的接口，因此 gate 必须设置为 3 级。

系统调用在每个 OS 实现上可能是不同的，#BP 异常必定是 vector 3，因此对于 vector 3 所使用的 gate 必须使用 3 级权限。

下面是在 windows 7 x64 操作系统上的 IDT 表的设置：

上面的粗体显示 interrupt gate 被设置为 3 级，在 windows 7 x64 下 vector 0x2c 和 0x2d 被设置为系统调用接口。实际上这两个 vector 的入口虽然不同，但是代码是一样的。你可以通过int 0x2c 和 int 0x2d 请求系统调用。

那么对于系统内部使用的 gate 我们应该保持与用户的隔离，绝大部分 interrupt handler 的 gate 权限都是设置为 0 级的。

2.5.2 interrupt handler 的 code segment 权限设置

前面说过：interrupt handler 的执行权限应该至少不低于调用者的权限，意味着 interrupt handler 需要在高权限级别下运行。无论是系统提供给用户的系统服务例程还是系统内部使用的 interrupt handler 我们都应该将 interrupt handler 设置为 0 级别的运行权限（最高权限），这样才能保证 interrupt handler 能访问系统的全部资源。

在权限检查方面，要求 DPLs 权限（interrupt handler 的执行权限）要高于或等于调用者的权限，也就是 CPL 权限，当数字上 DPLs 要小于等于 CPL（DPLs <= CPL）。

2.6 使用 interrupt gate

使用 interrupt gate 来构造中断调用机制的，当 processor 进入 interrupt handler 执行前，processor 会将 eflags 值压入栈中保存并且会清 eflags.IF 标志位，这意味着进入中断后不允许响应 makeable 中断（可屏蔽中断）。它的逻辑 C 描述为：

interrupt handler 使用 iret 指令返回时，会将栈中 eflags 值出栈以恢复原来的 eflags 值。

下面是 interrupt gate 的结构图：

可以看到 interrupt gate 和 trap gate 的结构是完全一样的，除了以 type 来区分 gate 外，interrupt gate 的类型是：

• 1110：32-bit interrupt gate
• 0110：16-bit interrupt gate

32 位的 offset 值提供了 interrupt handler 的入口偏移地址，这个偏移量是基于 code segment 的 base 值，selector 域提供了目标 code segment 的 selector，用来在 GDT 或 LDT 进行查找 code segment descriptor。这些域的使用描述为：

注得注意的是：在 interrupt gate 和 trap gate 中的 selector 它的 RPL 是不起作用的，这个 selector.RPL 将被忽略。

在 OS 的实现中大部分的 interrupt handler 都是使用 interrupt gate 进行构建的。在 windows 7 x64 系统上全部都使用 interrupt gate 并没有使用 trap gate

2.7 使用 trap gate

trap gate 在结构上与 interrupt gate 是完全一样的，参见节 2.6 的那图，trap gate 与 interrupt gate 不同的一点是：使用 trap gate 的，processor 进入 interrupt handler 前并不改变 eflags.IF 标志，这意味着在 interrupt handler 里将允许可屏蔽中断的响应。

2.8 使用 task gate

在使用 task gate 的情形下变得异常复杂，你需要为 new task 准备一个 task 信息的 TSS，然而你必须事先要设置好当前的 TSS 块，也就是说，系统中应该有两个 TSS 块：

• current TSS
• TSS of new task

当前的 TSS 是系统初始化设置好的，这个 TSS 的作用是：当发生 task 切换时保存当前 processor 的状态信（当前进程的 context 环境），新任务的 TSS 是通过 task gete 进行切换时使用的 TSS 块，这个 TSS 是存放新任务的入口信息。

在上面的示例代码中，设置了两个 TSS descriptor，一个供系统初始化使用（tss_desc），另一个是为新任务而设置（tss_task_gate），代码中必须设置两个 TSS 块：

• TSS
• TSS_TASKGATE

TSS 块的内容是什么在这个示例中无关紧要，然而 TSS_TASKGATE 块中应该设置新任务的入口信息，其中包括：eip 和 cs 值，以后必要的 DS 与 SS 寄存器值，还有 eflags 和 GPRs 值，下面的代码正是做这项工作：

我将新任务的入口点设为 BP_handler32()，这个是 #BP 断点异常处理程序，保存当前的 eflags 值作为新任务的 eflags 值。

我们必须为 task gate 设置相应的 IDT 表项，正如下面的示例代码：

示例代码中，我为 vector 3（#BP handler）设置为 task-gate descirptor，当发生 #BP 异常时，就会通过 task-gate 进行任务切换到我们的新任务（BP_handler32）。

当然我们应该先设置好 IDT 表和加载当前的 TSS 块，这个 TSS 块就是我们所定义的第1个 TSS descirptor (tss_desc），这个 TSS 块里什么内容都没有，设置它的目的是为切换到新任务时，保存当前任务的 context 环境，以便执行完新任务后切换回到原来的任务。

现在我们就可以测试我们的 BP_handler32()，通过 INT3 指令引发 #BP 异常，这个异常通过 task-gate 进行切换。

我们的 BP_handler32 代码是这样的：

它只是简单的显示一条信息，在这个 BP_handler32 中，我们应该要清 CR0.TS 标志位，这个标志位是通过 TSS 进行任务切换时，processor 自动设置的，然而 processsor 不会清 CR0.TS 标志位，需要代码中清除。

2.8.1 任务切换的情形

在本例中，我们来看看当进行任务切换时发生了什么，processor 会设置一些标志位：

• 置 CR0.TS = 1
• 置 eflags.NT = 1

设置 CR0.TS 标志位表示当前发生过任务切换，processor 只会置位，而不会清位，事实上，你应该使用 clts 指令进行清位工作。设置 eflags.NT 标志位表示当前任务是在嵌套层内，它指示当进行中断返回时，需切换回原来的任务，因此，请注意：

当 eflags.NT 被置位时，processor 执行另一个任务切换工作，从 TSS 块的 link 域中取出原来的 TSS selector 从而切换回原来的任务。这不像 ret 指令，它不会检查 eflags.NT 标志位。

processor 也会对 TSS descriptor 做一些设置标志，当进入新任务时，processor 会设置 new task 的 TSS descriptor 为 busy，当切换回原任务时，会置回这个任务的 TSS descriptor 为available，同时 processor 会检查 TSS 中的 link 域的 TSS selector（原任务的 TSS）是否为 busy，如果不为 busy 则会抛出 #TS 异常。

当然发生切换时 processor 会保存当前的 context 到 current TSS 块中，因此：

• 切换到目标任务时，processor 会保存当前的任务 context 到 TSS，读取目标任务的 TSS，加载相应的信息，然后进入目标任务
• 目标任务执行完后，切换回原任务时，processor 会保存目标任务的 context 到目标任务的 TSS 中，从目标任务的 TSS 块读取 link（原任务的 TSS selector)，加载相应的信息，返回到原任务

当从目标任务返回时，processor 会清目标任务的 eflags.NT = 0，如前所述目标任务的 TSS descriptor 也会被置为 available。