assembly - iretq 抛出 GP 错误
问题描述
我正在尝试编写一个 64 位操作系统。它从定时器中断处理程序的 iretq 上抛出一个 GP,然后从 GP 处理程序的 iretq 反复抛出更多的 GP。
我知道这一点,因为我的通用处理程序会在串行端口上打印 ISR 编号,它会变为 32、13、13、13,...
GP的错误代码是10,这是我的数据段。
我是在qemu中调试的,所以可以看到不少。这是定时器处理程序中 iretq 的情况:
(gdb) disas isr_common,isr_head_2
Dump of assembler code from 0x8189 to 0x81c4:
0x0000000000008189 <isr_common+0>: callq 0x8125 <sayN100>
0x000000000000818e <isr_common+5>: cmp $0x20,%eax
0x0000000000008191 <isr_common+8>: jl 0x81a8 <isr_common.no_more_acks>
0x0000000000008193 <isr_common+10>: cmp $0x30,%eax
0x0000000000008196 <isr_common+13>: jge 0x81a8 <isr_common.no_more_acks>
0x0000000000008198 <isr_common+15>: cmp $0x28,%al
0x000000000000819a <isr_common+17>: jl 0x81a2 <isr_common.ack_master>
0x000000000000819c <isr_common+19>: push %rax
0x000000000000819d <isr_common+20>: mov $0x20,%al
0x000000000000819f <isr_common+22>: out %al,$0xa0
0x00000000000081a1 <isr_common+24>: pop %rax
0x00000000000081a2 <isr_common.ack_master+0>: push %rax
0x00000000000081a3 <isr_common.ack_master+1>: mov $0x20,%al
0x00000000000081a5 <isr_common.ack_master+3>: out %al,$0x20
0x00000000000081a7 <isr_common.ack_master+5>: pop %rax
0x00000000000081a8 <isr_common.no_more_acks+0>: cmp $0x24,%ax
0x00000000000081ac <isr_common.no_more_acks+4>: pop %rax
0x00000000000081ad <isr_common.no_more_acks+5>: pop %rax
=> 0x00000000000081ae <isr_common.end+0>: iretq
0x00000000000081b0 <isr_head_0+0>: pushq $0x55 ;DUMMY ERROR CODE
0x00000000000081b2 <isr_head_0+2>: mov $0x0,%eax
0x00000000000081b7 <isr_head_0+7>: push %rax
0x00000000000081b8 <isr_head_0+8>: jmp 0x8189 <isr_common>
0x00000000000081ba <isr_head_1+0>: pushq $0x55 ;DUMMY ERROR CODE
0x00000000000081bc <isr_head_1+2>: mov $0x1,%eax
0x00000000000081c1 <isr_head_1+7>: push %rax
0x00000000000081c2 <isr_head_1+8>: jmp 0x8189 <isr_common>
这显示了在 IDT 中输入的几个“isr_head”,可能会将虚拟错误代码和 jmp 推送到 isr_common。
(gdb) bt
#0 0x00000000000081ae in isr_common.end ()
#1 0x0000000000008123 in LongMode.Nirv ()
#2 0x0000000000000010 in ?? ()
#3 0x0000000000000216 in ?? ()
#4 0x0000000000015000 in Pd ()
#5 0x0000000000000010 in ?? ()
#6 0x000000b8e5894855 in ?? ()
#7 0x78bf00000332e800 in ?? ()
#8 0x000003e3e8000000 in ?? ()
在哪里:
0x0000000000008122 <LongMode.Nirv+0>: hlt
0x0000000000008123 <LongMode.Nirv+1>: jmp 0x8122 <LongMode.Nirv>
要小心:
(gdb) info registers
rax 0x55 85
rbx 0x80000011 2147483665
rcx 0xc0000080 3221225600
rdx 0x3f8 1016
rsi 0xb 11
rdi 0x3fc 1020
rbp 0x0 0x0
rsp 0x14fd8 0x14fd8 <Pd+36824>
r8 0x0 0
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x0 0
r13 0x0 0
r14 0x0 0
r15 0x0 0
rip 0x81ae 0x81ae <isr_common.end>
eflags 0x97 [ CF PF AF SF ]
cs 0x8 8
ss 0x10 16
ds 0x10 16
es 0x10 16
fs 0x10 16
gs 0x10 16
(gdb) x/32xg 0x14f00
0x14f00 <Pd+36608>: 0x0000000000841f0f 0x000000841f0f2e66
0x14f10 <Pd+36624>: 0x00841f0f2e660000 0x1f0f2e6600000000
0x14f20 <Pd+36640>: 0x2e66000000000084 0x0000000000841f0f
0x14f30 <Pd+36656>: 0x000000841f0f2e66 0x00841f0f2e660000
0x14f40 <Pd+36672>: 0x1f0f2e6600000000 0x2e66000000000084
0x14f50 <Pd+36688>: 0x0000000000841f0f 0x000000841f0f2e66
0x14f60 <Pd+36704>: 0x00841f0f2e660000 0x1f0f2e6600000000
0x14f70 <Pd+36720>: 0x2e66000000000084 0x0000000000841f0f
0x14f80 <Pd+36736>: 0x000000841f0f2e66 0x00841f0f2e660000
0x14f90 <Pd+36752>: 0x1f0f2e6600000000 0x2e66000000000084
0x14fa0 <Pd+36768>: 0x0000000000000020 0x0000000000008144
0x14fb0 <Pd+36784>: 0x0000000080000011 0x0000000000000020
0x14fc0 <Pd+36800>: 0x0000000000000020 0x0000000000000020
0x14fd0 <Pd+36816>: 0x0000000000000055 0x0000000000008123
0x14fe0 <Pd+36832>: 0x0000000000000010 0x0000000000000216
0x14ff0 <Pd+36848>: 0x0000000000015000 0x0000000000000010
现在我让它运行到 GP 处理程序头:
(gdb) break isr_head_13
Breakpoint 3 at 0x8236
(gdb) c
Continuing.
Breakpoint 3, 0x0000000000008236 in isr_head_13 ()
(gdb) bt
#0 0x0000000000008236 in isr_head_13 ()
#1 0x0000000000000010 in ?? ()
#2 0x00000000000081ae in isr_common.no_more_acks ()
#3 0x0000000000000008 in ?? ()
#4 0x0000000000000097 in ?? ()
#5 0x0000000000014fd8 in Pd ()
#6 0x0000000000000010 in ?? ()
#7 0x0000000000000055 in ?? ()
#8 0x0000000000008123 in LongMode.Nirv ()
#9 0x0000000000000010 in ?? ()
#10 0x0000000000000216 in ?? ()
#11 0x0000000000015000 in Pd ()
#12 0x0000000000000010 in ?? ()
我们看到它在带有选择器、标志和返回地址的通常堆栈之后推送了错误代码 0x10,但有趣的是我的来自计时器 (0x55) 的虚拟错误代码起死回生。我们已经知道它是由第一个 iretq 弹出的,这次我没有推送它:
(gdb) disas isr_head_13
Dump of assembler code for function isr_head_13:
=> 0x0000000000008236 <+0>: mov $0xd,%eax
0x000000000000823b <+5>: push %rax
0x000000000000823c <+6>: jmpq 0x8189 <isr_common>
我想这只是 16 字节对齐,但我并没有真正参与其中。在计时器关闭之前堆栈是 16 字节对齐的,但 CPU 推送了奇数个 longlong。
那么它为什么会崩溃呢?英特尔文档说带有选择器的 GP 意味着它试图弹出超出范围的东西,但我没有看到这样的问题。
非常感谢任何帮助。
解决方案
第一个 IRET 时堆栈上的 CS 选择器是 10,这是一个数据段,所以这就是导致 #GP 的原因。要么在处理程序中修改了堆栈(似乎不是这种情况),要么在更改 GDT 后未重新加载 CS 寄存器。
来自 GP 处理程序的 IRET 返回到先前的 IRET,该 IRET 立即再次出现故障。除非您已解决故障,否则您通常不应从故障处理程序返回。
它看起来不像保存和恢复处理程序中的所有寄存器,一旦 IRET 开始工作,这将导致问题。
推荐阅读
- node.js - 从 docker compose 运行 REST API 测试
- python - 如何将嵌套的 if/else 函数调用转换为 python 中的字典?
- reactjs - 如何制作表单 ReactJS 原子设计
- c# - 为什么立方体网格在高分辨率时会变成平面?
- python - 熊猫数据框无效键
- machine-learning - 如何在特征重要性条形图上显示特征名称?
- django - JWT 身份验证在带有 SimpleJWT 的 Django Rest Framework 中返回 AnonymousUser
- c++ - 如何统计数组中的重复元素并将它们放入不同的数组中
- python - 模糊 c 均值聚类
- c++ - Visual C++ - 文件夹结构