7

考虑以下汇编程序：

bits 64
global _start
_start:
    mov rax, 0x0000111111111111
    add byte [rax*1+0x0], al
    jmp _start

当您使用nasmand ld（在 Ubuntu，内核 5.4.0-48-generic，Ryzen 3900X 上）编译它时，您会得到一个段错误：

$ ./segfault-addr
[1]    107116 segmentation fault (core dumped)  ./segfault-addr

附加gdb后，您可以看到导致此故障的地址：

(gdb) p $_siginfo._sifields._sigfault.si_addr
$1 = (void *) 0x111111111111

但是，如果您将 16 个最高有效位中的任何一个设置为 1，如下所示：

bits 64
global _start
_start:
    mov rax, 0x0001111111111111
    add byte [rax*1+0x0], al
    jmp _start

您显然仍然会遇到段错误，但现在地址为 NULL：

(gdb) p $_siginfo._sifields._sigfault.si_addr
$1 = (void *) 0x0

为什么会这样？是gdbLinux，还是CPU本身造成的？

我能做些什么来防止这种行为吗？

4

1 回答 1

6

这是规范地址和非规范地址之间的区别，因为 x86-64 没有完整的 64 位虚拟地址空间。您的第二个示例是非规范地址，因为它不是符号扩展的 48 位值（您的机器上显然没有 5 级页表扩展名，否则它将是 57 位）；这样的地址永远无法解析为物理内存位置。

对规范地址的无效访问会产生页面错误 (#PF)，CPU 会为此向内核提供错误地址（在 CR2 寄存器中），然后内核将其传递给si_addr字段中的用户空间，struct siginfo如您所见。但是对非规范地址的访问总是无效的，并且 CPU 会引发一般保护异常 (#GP)，或者在极少数情况下会引发堆栈错误 (#SS)。x86 架构的设计者以他们无限的智慧选择在#GP 或#SS 异常的情况下不向软件提供错误地址，因此内核不会得到它，你也不会。

如果您确实需要该地址，您唯一的选择是解码导致异常的指令，并根据需要检查寄存器的内容以找出它试图做什么。

我认为这个决定是因为内核在页面错误的情况下确实需要地址。访问不存在的页面可能是内存冲突，应该终止进程；或者，例如，它可能只是从物理内存中换出的页面。在后一种情况下，内核使用故障地址在磁盘上找到适当的页面并将其加载回物理内存。然后它更新页表并从异常处理程序返回以重新启动故障指令，程序可以继续。

但是，一般保护故障通常是不可恢复的，并且必须终止该进程，或者至少发出信号以便它可以尝试清理。在这种情况下，对错误地址没有什么可操作的，我猜架构设计者认为它的潜在调试价值不值得让 CPU 保存它。无论如何，#GP 的许多可能原因根本不是由内存访问引起的（例如，尝试从非特权模式读取或写入控制寄存器），在这种情况下没有错误地址。

于 2020-10-12T05:19:30.803 回答