`%fs:0xfffffffffffffff8` 的真实地址是什么？

Question

我想使用ebpf.在阅读了一些帖子和博客之后，我知道%fs:0xfffffffffffffff8指向ggo 的结构和mov %fs:0xfffffffffffffff8,%rcx指令总是出现在 go 函数的开头。举main.main个例子：func main() { 177341   458330:   64 48 8b 0c 25 f8 ff    mov    %fs:0xfffffffffffffff8,%rcx 177342   458337:   ff ff 177343   458339:   48 3b 61 10             cmp    0x10(%rcx),%rsp 177344   45833d:   76 1a                   jbe    458359 <main.main+0x29> 177345   45833f:   48 83 ec 08             sub    $0x8,%rsp 177346   458343:   48 89 2c 24             mov    %rbp,(%rsp) 177347   458347:   48 8d 2c 24             lea    (%rsp),%rbp 177348     myFunc() 177349   45834b:   e8 10 00 00 00          callq  458360 <main.myFunc> 177350 }我也知道 goid 信息存储在ggo 的 struct 中。fs 寄存器的值可以通过函数的ctx参数获取ebpf。但我不知道真正的地址是什么，%fs:0xfffffffffffffff8因为我是汇编语言的新手。谁能给我一些提示？如果 fs 寄存器的值为 0x88，那么 的值是%fs:0xfffffffffffffff8多少？

Answer 1

这是一个负数，所以它是 FS 基数之前的一个 qword。您需要 FS 基地址，它不是您可以通过调试器看到的 FS 段寄存器中的选择器值。

您的进程可能进行了系统调用以要求操作系统对其进行设置，或者可能wrfsbase在支持它的系统上的某个时候使用了该指令。

请注意，至少在 Go 之外，Linux 通常使用 FS 进行线程本地存储。

（我不确定实际找到 FS 基础的标准方法是什么；在rdmsr不可用的用户空间中执行此操作显然取决于操作系统；FS 和 GS 基础作为 MSR 公开，因此操作系统使用它而不是实际修改 GDT 或 LDT 条目。 rdfsbase需要通过内核在支持 FSGSBASE ISA 扩展的 CPU 上的 CR4 中设置一个位来启用，所以你不能指望它工作。）

@MargaretBloom 建议用户空间可能触发无效页面错误；大多数操作系统将错误的虚拟地址报告回用户空间。例如，在 Linux 中，SIGSEGV 具有地址。（如果它是非规范的，则为 SIGBUS，IIRC。即不在虚拟地址空间的低 47 位或高 47 位中，而是在地址不是低 48 的符号扩展的“洞”中。）

因此，您需要为这些信号安装信号处理程序，并尝试从位于内核空间中间的偏移量（基数为 0）或类似的地方加载。如果由于某种原因没有故障，请将虚拟地址增加 1TiB 或循环中的某些内容。通常没有 MMIO 映射到用户空间的虚拟地址空间，因此仅读取没有副作用。