完成IDT配置后执行sti指令导致程序崩溃的问题排查

核心症状 #

完成IDT（条目、表及描述符）全量配置后，执行sti指令直接引发程序崩溃，最终触发Triple fault。

已验证的关键信息 #

• 中断处理函数地址与idt_table对应条目存储的地址完全匹配；
• IDT条目的属性字段（IST、权限标志、存在位等）均符合预期配置；
• IDT描述符（idt_descriptor）的limit与base值配置正确；
• 通过sidt指令验证，idtr寄存器加载的IDT基址和限长与预期一致；
• 将原C实现重写为纯汇编代码后问题复现，排除GCC编译或优化导致的异常；
• 测试阶段已将所有255个中断向量绑定至同一通用处理程序，问题未消失。

运行环境 #

• 虚拟机：QEMU
• 模式：Long模式（已完成虚拟/物理内存映射，非初始化阶段）
• 工具链：WSL下的GCC编译器+自定义链接脚本

调试捕获的异常链 #

程序运行中多次触发SMM进入与退出，最终触发硬件中断0x08（双重故障异常），随后引发异常切换，最终触发Triple fault。

重点排查方向 #

1. SMM相关的内存/状态干扰
   由于调试中出现多次SMM进入退出，需确认SMM模式下是否修改了IDT相关内存区域、idtr寄存器或中断状态位（如IF标志）。SMM拥有最高权限，可能在退出时未正确恢复原有的中断配置状态。

2. 中断0x08的根源定位
   中断0x08是双重故障，说明在处理某个初始异常时又触发了另一个异常。需检查：

   • 通用中断处理程序的栈配置是否正确：Long模式下中断栈需满足16字节对齐，且IST（如果启用）对应的TSS栈段是否已正确初始化（物理地址有效、栈大小足够）；
   • 中断处理程序的入口代码是否存在错误：比如未正确保存/恢复寄存器、指令长度错误（如32位代码混入64位环境）；
   • 内存分页配置：确认IDT表所在内存区域、中断处理程序所在区域的页表属性是否正确（如是否设置为可执行、是否存在映射）。

3. sti执行后的首个中断触发
   sti会开启中断标志，此时可能有pending的硬件中断立即触发。需确认：

   • 硬件设备是否有未处理的中断请求（如PIT、PIC/IOAPIC的配置是否正确，是否存在误触发的中断）；
   • 中断控制器的掩码状态：是否在配置IDT前未正确屏蔽所有中断，导致sti后立即触发未预期的中断。

4. TSS与栈帧的正确性
   若使用了IST，需确认TSS中的IST栈指针是否指向有效的物理内存，且栈空间未被其他代码覆盖。即使未使用IST，内核栈的指针（rsp）在sti执行时需处于有效且足够的栈空间内。

内容的提问来源于stack exchange，提问作者Adi Mehmedičević