x86保护模式分页启用异常：CR3寄存器始终为0求助

一、CR3寄存器始终为0的排查方向 #

1. 确认CR3加载的时机与权限

   • 实模式下无法操作CR3寄存器，必须先完成保护模式切换（将CR0的PE位置1），再执行mov cr3, eax这类指令加载页表物理地址。检查代码是否在保护模式就绪后才执行CR3加载操作。
   • 确保加载CR3时使用的数据段具备DPL=0、可写的权限，权限不足会触发保护异常，导致指令未执行。

2. 验证页表物理地址的有效性

   • 你预期CR3值为0x00008000，需确认页表确实被加载到物理地址0x8000：
     • 检查交叉编译的链接脚本，确保页表对应的段被分配到正确物理地址，避免被bootloader或BIOS初始化代码覆盖。
     • 通过QEMU命令x/10x 0x8000查看该地址是否存在正确的页表项。

3. 检查代码执行流程

   • 反汇编加载CR3的代码段，确认指令编译正确，且程序执行流确实到达该指令。排查是否存在跳转错误、初始化顺序颠倒（如先开分页再加载CR3）等问题。

4. 排查分页开启的顺序

   • 若开启分页，需先加载CR3，再置位CR0的PG位。先开分页再加载CR3会导致CPU使用无效页表，可能出现异常或CR3未更新的情况。

二、CS段值差异的说明 #

你看到的CS段值00cf9b00与他人的00cf9a00仅差异在访问位（A位）：

• 段描述符属性字节的最低位是A位，CPU访问该段后会自动置1。
• 0x9a对应属性：代码段、只读、非一致、DPL=0、未访问；0x9b对应属性：代码段、只读、非一致、DPL=0、已访问。
• 该差异是正常现象，仅说明你的CS段已被CPU执行过指令，属于硬件正常标记，并非配置错误。

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