IDT系列：（一）初探IDT，Interrupt Descriptor Table，中断描述符表

IDT，Interrupt Descriptor Table，中断描述符表是CPU用来处理中断和程序异常的。

 

一、有关IDT的基本知识

1、中断时一种机制，用来处理硬件需要向CPU输入信息的情况。 比如鼠标，键盘等。

2、中断和异常的产生是随机的，在CPU正常运行过程中随时可能产生。CPU的中断处理机制

3、中断可以由硬件产生（称为外部中断），也可以由软件产生（称为内部中断），在程序中写入int n指令可以产生n号中断和异常（n从0-ffh）。

 

4、同时CPU的中断异常机制还是重要特性的支持原理，比如程序调试，程序运行过程中的异常处理（如零除数异常、内存分页错误等）。 

5、早期的操作系统甚至是通过中断来进行内核调用的。int指令是一种c从ring3 进入ring 0的方法。比如windows在xp版本之前使用的int 2e。在x86 CPU提供了sysenter指令后，这种方式才被放弃。

6、每一种中断对应一个中断号。CPU执行中断指令时，会去IDT表中查找对应的中断服务程序（interrupt service routine ，ISR）。ISR（为了表述方便后面用ISR n表示n号中断的处理程序），x86CPU最大可以支持256种中断。

 7、中断是CPU的机制，不管运行的是什么操作系统，只有是运行于x86架构，IDT结构式必然存在的。IDT表中的ISRs应该有操作系统提供。

8、异常分为错误（Faults）、陷阱（Traps）和终止（Aborts）三种，其区别是“错误”允许产生错误的程序继续允许，“陷阱”也可以，但是“错误”产生于指令执行后，而“陷阱”需要在产生异常的指令执行后，因此从“错误”中返回时继续执行产生错误的指令，而从“陷阱返”回时应当从产生异常的指令后开始执行。终止产生时，处理程序不能得到精确的异常产生的代码位置，程序不能继续进行，硬件错误会产生“终止”。 例如page faults就是一个faults，mov [eax], ecx，产生了一个分页错误，表面[eax]内存是无效，需要先进行分页处理从新映射物理内存然后才能继续进行mov操作；而断点是一个Trap。

9、Intel指定或保留了前32个中断号的作用，操作系统可以指定其余的中断号的作用。

10、中断的过程中可以产生新的中断。中断时有优先级的，高优先级的中断可以“中断”低优先级的中断。有的ISR不能被中断，可以使用STI (set interrupt-enable flag) and CLI(clear interrupt-enable flag)设置IF标志来启动和关闭中断。

 

（更详细的内容可以参考Intel® 64 and IA-32 Architectures Software Developer’s Manual）

 

二、IDT表的结构

中断处理过程是有CPU直接调用的，CPU有专门的寄存器IDTR来保存IDT在内存中的位置，本文写为IDTR.base。IDTR有48为，前32为是IDT在内存中的位置（线性地址），后16为是IDT的大小，本文写为IDT.limit。程序可以使用LIDT和SIDT指令来读写IDTR。

IDT是一个最大为256项的表，每个表项为8字节。称为中断门。CPU通过IDT.base+n*8来寻找门。

根据中断号对应的异常类型不同（Faults/Traps/Aborts）8个字节的意义也不同。

如上图所示IDT门中的最后两个byte是ISR在内存中的高16位，最开始前两个字节是ISR在内存中地址的低16位。

 

三、使用WinDbg观察、调试IDT

使用Vmware配置好内核调试环境[link]。

 

WinDbg有支持查看IDT的扩展命令!idt

!idt –a 命令可以看到所有中断处理函数的地址。
r idtr 参看idtr寄存器中保存的idt表地址。
idt每个表项有8bytes，两个dword大。

（注意.reload /i 加载符号文件）

kd> !idt -a

Dumping IDT:

00: 8053f19c nt!KiTrap00
01: 8053f314 nt!KiTrap01
02: Task Selector = 0x0058
03: 8053f6e4 nt!KiTrap03
04: 8053f864 nt!KiTrap04
05: 8053f9c0 nt!KiTrap05
06: 8053fb34 nt!KiTrap06
07: 8054019c nt!KiTrap07
08: Task Selector = 0x0050
09: 805405c0 nt!KiTrap09
0a: 805406e0 nt!KiTrap0A
0b: 80540820 nt!KiTrap0B
0c: 80540a7c nt!KiTrap0C
0d: 80540d60 nt!KiTrap0D
0e: 80541450 nt!KiTrap0E
… …

kd> r idtr
idtr=8003f400
kd> db idtr
8003f400  9c f1 08 00 00 8e 53 80-14 f3 08 00 00 8e 53 80  ......S.......S.
8003f410  3e 11 58 00 00 85 00 00-e4 f6 08 00 00 ee 53 80  >.X...........S.
8003f420  64 f8 08 00 00 ee 53 80-c0 f9 08 00 00 8e 53 80  d.....S.......S.
8003f430  34 fb 08 00 00 8e 53 80-9c 01 08 00 00 8e 54 80  4.....S.......T.
8003f440  98 11 50 00 00 85 00 00-c0 05 08 00 00 8e 54 80  ..P...........T.
8003f450  e0 06 08 00 00 8e 54 80-20 08 08 00 00 8e 54 80  ......T. .....T.
8003f460  7c 0a 08 00 00 8e 54 80-60 0d 08 00 00 8e 54 80  |.....T.`.....T.
8003f470  50 14 08 00 00 8e 54 80-80 17 08 00 00 8e 54 80  P.....T.......T.

 

可以看到，这个时候IDT的基地址是在803f400处。
注意观察其中3号中断门 e4 f6 08 00 00 ee 53 80 ISR 3
int 3是trap门,按照之前说的ISR地址构造方法，得到8053f6e4的中断服务程序地址。

 

 

 

好，我们观察了IDT表（知道了IDT表的结构，自己写一个!idt WinDbg扩展也是很简单的事情），但是，使用windbg调试IDT表式不可能的。WinDbg的工作就要依赖于debuggee系统的中断向量，如果在ISR 3里写个int 3，那么BSOD是绝对的。Windbg和Debuggee系统是通过com口连接的，当Debuggee系统中产生了int3中断，系统首先进入到ISR 3中。在ISR 3中判断存在内核调试器，然后通过com口和WinDbg通行。这个处理过程本身就依赖于Debuggee系统的ISR。如果在ISR 3中又存在一个int 3那么就无限递归了。
 （待续）