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

Question

考虑以下汇编程序:

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

当你用 nasm 编译它时和 ld (在 Ubuntu 上，内核 5.4.0-48-generic，Ryzen 3900X)，你会得到一个段错误:

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

When you attach gdb you can see the address that caused this fault :

(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

这是canonical and non-canonical addresses之间的区别，因为 x86-64 没有完整的 64 位虚拟地址空间。您的第二个示例是非规范地址，因为它不是符号扩展的 48 位值(您的机器上显然没有 5 级页表扩展，否则它将是 57 位)；此类地址永远无法解析为物理内存位置。
对规范地址的无效访问会产生页面错误 (#PF)，为此 CPU 将错误地址提供给内核(在 CR2 寄存器中)，内核将其传递到 si_addr 中的用户空间领域struct siginfo正如你看到的。但是对非规范地址的访问总是无效的，并且 CPU 会引发一般保护异常 (#GP)，或者在极少数情况下会引发堆栈错误 (#SS)。 x86 架构的设计者以他们无限的智慧选择在出现 #GP 或 #SS 异常时不向软件提供错误地址，因此内核无法获得它，您也无法获得。
如果你真的需要地址，你唯一的选择就是解码导致异常的指令，并根据需要检查寄存器的内容以确定它试图做什么。

我认为这个决定是因为内核确实需要在页面错误的情况下的地址。访问一个不存在的页面可能是一个应该终止进程的内存冲突；或者，例如，它可能只是从物理内存中换出的页面。在后一种情况下，内核使用故障地址在磁盘上找到合适的页面并将其加载回物理内存。然后它更新页表并从异常处理程序返回以重新启动出错指令，程序可以继续。
然而，一般的保护故障通常是不可恢复的，并且必须终止该进程，或者至少发出信号以便它可以尝试清理。在这种情况下，对于故障地址没有什么可操作的，我猜架构设计者不认为它的潜在调试值(value)值得让 CPU 保存它。无论如何，#GP 的许多可能原因根本不是由内存访问引起的(例如，尝试从非特权模式读取或写入控制寄存器)，在这种情况下没有错误地址。