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

Question

我想使用 ebpf 跟踪 go 程序的 goid .

在阅读了一些帖子和博客后，我知道 %fs:0xfffffffffffffff8指向g go 和 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信息存储在 g中去结构。 fs 寄存器的值可以通过 ctx 获得 ebpf 的论据功能。

但不知道 %fs:0xfffffffffffffff8的真实地址是什么因为我是汇编语言的新手。谁能给我一些提示？

如果fs寄存器的值为0x88，那么 %fs:0xfffffffffffffff8的值是多少？ ?

Answer 1

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

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

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

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

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

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