为什么在访问设置了 16 个最高有效位中的任何一个的内存时段错误地址为 NULL？

Question

考虑以下汇编程序：

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

为什么会这样？是由gdb、Linux 还是 CPU 本身引起的？

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

Answer 1

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

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

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

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

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