x86_64 OS中GDT选择子1113引发通用保护故障的原因排查

1. 解析错误码与选择子 #

GPF错误码0x22C8对应x86_64规范的含义：

• bit0=1：故障由外部中断/异常触发
• bit1=0：问题出在GDT/LDT选择子，而非IDT条目
• bit2=1：选择子指向LDT（但你未配置LDT，这是核心矛盾点）
• 选择子索引：0x2C8 >> 3 = 0x59（89号条目），远超过你GDT的5个条目范围

这说明iretq执行时，栈上的CS选择子完全无效——要么误设了TI位指向不存在的LDT，要么索引超出GDT范围，要么特权级（RPL）不匹配。

2. 检查iretq栈上下文 #

iretq依赖栈上的返回数据（顺序从上到下）：

[RSP+0x00] RIP
[RSP+0x08] CS
[RSP+0x10] RFLAGS
[RSP+0x18] RSP（用户态返回时）
[RSP+0x20] SS（用户态返回时）

在VirtualBox触发故障时暂停调试，核对这些值：

• 确认CS选择子的TI位（bit2）是否为0（指向GDT），索引是否在0-4（你的GDT条目数）
• 检查CS的RPL位（bit0-1）：内核态返回时RPL必须为0；用户态返回时RPL需为3，且SS的RPL必须与CS一致
• 若返回用户态，确认SS选择子是否指向GDT中有效的数据段

3. 对比Qemu与VirtualBox的GDT合规性 #

Qemu对x86规范的检查较为宽松，VirtualBox严格遵循标准，重点核对：

• GDT描述符的关键位：内核代码段需设L=1（64位模式）、D/B=0；数据段设D/B=1、L=0
• lgdt参数：限长必须是(条目数×8)-1（5个条目即5×8-1=39），基地址需8字节对齐
• 加载GDT后是否执行far jmp刷新CS寄存器（64位模式下无法用mov直接修改CS，必须通过远跳转更新）
• DS/ES/FS/GS是否设置为0（64位模式下这些段寄存器仅作占位，无需实际段）

4. 检查中断栈帧的保存逻辑 #

若故障发生在中断返回时，核对中断入口汇编：

• 确认栈帧保存时未破坏8字节对齐（iretq要求执行前RSP为8字节对齐，VirtualBox对此检查更严格）
• 排查是否在中断处理中错误覆盖了栈上的CS/RIP等返回上下文数据

5. 验证VirtualBox的CPU配置 #

• 确认已启用硬件虚拟化（VT-x/AMD-V），禁用后可能导致模式切换异常
• 检查虚拟机CPU是否设置为64位，且开启PAE、PSE等必要特性
• 尝试关闭嵌套分页，观察故障是否消失或变化

6. 核对Limine引导后的过渡逻辑 #

Limine已完成长模式切换，需确认你的内核代码是否正确接管：

• 自定义GDT加载后，是否所有段寄存器都切换到新选择子，无Limine残留的段选择子
• 确认未在长模式下错误使用16/32位段属性的选择子

内容的提问来源于stack exchange，提问作者baponkar