极客教程

Appearance

共 1,899 字预计阅读约 6 分钟

段管理的观测与调试 —— 用 gdb 亲眼看 CS=0x33、FS_BASE、GDT 与段权限实验 ​

前面几篇（演进、GDT 与特权级切换）讲完了理论，这篇全部是"动手看真东西"：用 gdb 在断点处看真实进程的段寄存器快照并逐项对照理论预测（CS=0x33、SS=0x2b、DS/ES/FS/GS=0、fs_base 是 TLS 基址）；用 debugfs/rdmsr 看 GDT 内容和 MSR；写一段会触发 #GP 的汇编验证段权限；用 bpftrace 观测 syscall 进出时的段寄存器跳变；最后解释为什么"段选择子是 0 程序还能跑"。

相关：理论依据见演进篇与GDT 篇；总纲见 segment-management。

一、为什么要自己动手看 ​

段机制是 CPU 硬件行为，平时完全"隐形"——你写的每个 C 程序都在用它（CS=0x33），但几乎不会注意到。gdb 能直接把段寄存器、隐藏的 fs_base、gs_base 打出来，是验证前面理论最直接的方式：理论预测的值和实测快照逐项对照，比读十遍文档都管用。

二、查看当前段寄存器 ​

方法一：gdb 完整寄存器快照（最真实）

在 main() 返回前打一个断点（break main，run 到 return 0），执行 info registers：

bash
$ gdb ./find
(gdb) break find.cpp:9           # return 0 那行
(gdb) run
Breakpoint 1, main () at find.cpp:9
9           return 0;
(gdb) info registers
rax             0x400612          4195858        ; main() 的返回值（0 不在这里——见下）
rbx             0x0               0
rcx             0x100             256
rdx             0x7fffffffc9f8    140737488341496  ; argv 指针
rsi             0x7fffffffc9e8    140737488341480  ; argc
rdi             0x1               1
rbp             0x7fffffffc900    0x7fffffffc900
rsp             0x7fffffffc900    0x7fffffffc900  ; 栈顶（RBP=RSP，无栈帧）
r8              0x7fff74ede80     ...
r9              0x0
r10             0x7ffffffbbce0
r11             0x7fff715ef30
r12             0x400540          4195648
r13             0x7fffffffc9e0
r14             0x0
r15             0x0
rip             0x400616          0x400616 <main()+4>  ; PIE 二进制基址 0x400000
eflags          0x246             [ PF ZF IF ]         ; PF=1 上一条指令结果为偶、ZF=1、IF=1 中断开
cs              0x33              51                   ; ★ 用户代码段（GDT[6], RPL=3）
ss              0x2b              43                   ; ★ 用户数据/栈段（GDT[5], RPL=3）
ds              0x0               0                    ; 长模式忽略基址/界限
es              0x0               0
fs              0x0               0                    ; 选择子为 0，但 fs_base 有值
gs              0x0               0
fs_base         0x7ffff7dd4740    140737353959232      ; ★ TLS 基址（arch_prctl/ARCH_SET_FS 设置）
gs_base         0x0               0                    ; 内核用 swapgs 切换

这份快照与理论预测的对应关系：

寄存器实测值理论预测解读
CS0x330x33（GDT[6]）用户态代码段，RPL=3
SS0x2b0x2B（GDT[5]）用户态栈段，RPL=3
DS/ES/FS/GS0x0被忽略选择子 0 = 指向 GDT[0]（NULL 描述符），长模式不检查基址/界限
fs_base0x7ffff7dd4740进程 TLS 区域这是动态链接器 glibc 为主线程设置的 TLS 基址，访问 fs:[0] 实际访问这里
gs_base0x00用户态 GS 未设置，内核会通过 swapgs 切到 per-CPU 基址
RSP0x7fffffffc900用户栈顶典型 48 位虚拟地址高位，栈向低地址增长
RIP0x400616PIE 二进制非 PIE 二进制默认加载到 0x400000 段，PIE 则在更高的随机地址
eflags0x246 = 0b 0010 0100 0110—bit 1=TF(陷阱)、bit 9=IF(中断开)、bit 11=ZF(零标志=1，因 return 0 准备写 0)、bit 14=嵌套任务，bit 6/3/0 是固定 1

关键观察：DS/ES/FS/GS 选择子是 0x0（指向 GDT[0] NULL 描述符）但程序仍能正常运行——这就是长模式"扁平化"的体现：硬件不读这些段选择子里的基址/界限，所以选 NULL 也无所谓；CPU 内部只关心 CS.Selector.RPL 决定 CPL，以及 fs_base/gs_base 这两个独立的 MSR。

方法二：单独看段寄存器（精简版）

bash
(gdb) info registers cs ds es fs gs ss
cs             0x33     51
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
ss             0x2b     43

方法三：看 fs/gs 的隐藏基址寄存器

bash
(gdb) info registers fs_base gs_base
fs_base         0x7ffff7dd4740
gs_base         0x0

默认 gdb 不会自动显示 fs_base/gs_base，需要用 info registers 完整输出（见方法一），或显式 print $fs_base。这是排查线程局部存储（TLS）问题时的关键寄存器。

方法四：通过 /proc 查看（需要在内核中打印）

c
// 在内核模块或 eBPF 中读 task_struct->thread.fsbase/gsbase
pr_info("FS base = 0x%lx\n", current->thread.fsbase);

用户态无法直接读自己/他人的 fs_base（arch_prctl(ARCH_GET_FS, ...) 只能读自己的，且需要 root 或合适权限）。

三、查看 GDT 内容 ​

bash
# 通过 debugfs 查看（需要 root）
sudo cat /sys/kernel/debug/x86/gdt | head -20
# 或者用 rdmsr 读 GDTR
sudo rdmsr 0xC0000081   # MSR_STAR

四、验证段权限：一段必然崩溃的代码 ​

c
// 测试：用户态尝试加载内核段选择子
// 预期：收到 SIGSEGV
#include <stdio.h>
int main() {
    unsigned short kernel_ds = 0x18;  // 内核数据段
    // 下面的内联汇编会触发 #GP(0)
    // 内核将其转为 SIGSEGV
    __asm__ volatile (
        "movw %0, %%ds\n\t"
        :
        : "r"(kernel_ds)
        :
    );
    printf("如果看到这行，说明段保护失效了\n");  // 永远到不了这里
    return 0;
}

运行预期：mov ds, 0x18 在用户态触发 #GP(0)，内核把它转成 SIGSEGV 递交给进程，进程直接崩溃——"如果看到这行"永远不会打印。这就是 GDT 篇 §2.1 权限检查公式 max(CPL=3, RPL=0) = 3 > DPL=0 的现场验证。注意这段程序在 32 位用户态环境（__asm__ volatile 用 movw）下也能触发相同效果。

五、查看 MSR 寄存器 ​

bash
sudo rdmsr 0xC0000082  # MSR_LSTAR — syscall 入口地址
sudo rdmsr 0xC0000081  # MSR_STAR — 段选择子配置
sudo rdmsr 0xC0000084  # MSR_FMASK — 标志清除掩码

rdmsr 需要 msr-tools 包和 root 权限，读出来的是十六进制原始值。MSR_STAR 的 [63:48] 是用户 CS/SS 基值 0x30、[47:32] 是内核 CS/SS 基值 0x10，正好对应GDT 与特权级切换篇的 MSR_STAR 布局。

六、用 bpftrace 观测 syscall 进出时的段寄存器跳变 ​

静态断点只能看"某一刻"的快照，想观测"特权级切换瞬间段寄存器怎么变"，可以用 bpftrace 在 sys_enter/sys_exit 探针上抓取当前 CS：

bash
# 观测每次系统调用进出时 CPL 的变化（内核态 CS=0x10 vs 用户态 CS=0x33）
sudo bpftrace -e '
tracepoint:raw_syscalls:sys_enter {
  printf("enter: comm=%s CS=0x%x\n", comm, reg("cs"));
}
tracepoint:raw_syscalls:sys_exit {
  printf("exit:  comm=%s CS=0x%x\n", comm, reg("cs"));
}'

运行一次 ls，输出大致如下（节选）：

bash
enter: comm=ls CS=0x10      # 已在内核态，CS=0x10（内核代码段）
exit:  comm=ls CS=0x10      # 返回路径仍在内核态
...（每个 syscall 两行，CS 都是 0x10）
# 注意：用户态快照抓不到——探针只在进入/离开内核时触发

这印证了特权级切换篇的一个要点：用户态看不到自己 CS=0x33 的执行现场——每次进 syscall，CS 立刻被硬件切成 0x10（内核段），返回时切回 0x33。想在用户态看 CS=0x33，只能像前面那样用 gdb 断点停住再 info registers。bpftrace 观测的"边界效应"本身就是段切换机制的证据。

七、线程 TLS 观测：fs_base 如何随线程变化 ​

fs_base 是 TLS 的载体，多线程程序里每个线程的 fs_base 指向各自独立的 TLS 区。用 gdb 切线程就能看到：

bash
(gdb) break main
(gdb) run
(gdb) info threads
* 1    Thread 0x7ffff7dd4740 (LWP 12345)  main ()
  2    Thread 0x7ffff6e6f700 (LWP 12346)  worker ()
(gdb) thread 2
(gdb) print $fs_base
$1 = 0x7ffff6e6f700     # ★ worker 线程的 fs_base 指向自己的栈/TLS 区
(gdb) thread 1
(gdb) print $fs_base
$2 = 0x7ffff7dd4740     # 主线程的 fs_base 指向自己的 TLS 区

实践意义：如果你用 -fsanitize=thread 或 perf 看线程局部变量，地址总落在 fs_base 附近；一旦发现两个线程的 fs_base 相同或相差很小，往往意味着 TLS 初始化 bug（比如 TLS 区被错误共享）。这也是排查"线程局部变量互相污染"时的第一手线索。

七·五、段寄存器与性能：为什么 fs_base 影响缓存命中 ​

段管理在 x86-64 下不做地址翻译，但 fs_base/gs_base 有一个实打实的性能影响——TLS 访问的缓存/TLB 行为。

  • 每次访问 fs:[offset]（线程局部变量、errno、pthread 内部状态），CPU 都要用 fs_base 做一次地址计算 + 一次额外的页表查询（如果 fs_base 所在的页不在 TLB）。
  • 多线程频繁切线程时，各线程 fs_base 指向不同 TLS 区，TLS 页在不同线程间切换导致 TLB 抖动——这是某些高并发程序"线程数上去反而变慢"的隐藏原因之一。
  • 优化手段：让 TLS 区尽量小、尽量对齐到同一页；用 __thread 大块结构时考虑是否值得（每线程一份副本的空间/TLB 代价）。

排查提示：perf record 火焰图里如果看到大量时间花在 __errno_location、pthread_getspecific 这类 TLS 访问函数上，优先怀疑 TLB 抖动（用 perf stat -e dTLB-load-misses 佐证），而不是直接怪"线程太多"。

八、常见问题排查清单 ​

症状可能原因排查手段
程序一跑就 SIGSEGV，gdb 停在 mov ds 附近用户态尝试加载内核段（DPL 检查失败）info registers cs ds，对照 max(CPL,RPL) > DPL 公式
fs:[0] 访问到错误地址 / 线程变量串台TLS 基址错误（arch_prctl 设置失败）多线程下分别 print $fs_base 对比
内核日志 general protection fault + 用户地址用户态 syscall 参数异常或段寄存器被污染dmesg 看 RIP，info registers cs ss
gdb 里看不到 fs_base老版本 gdb 默认不显示显式 print $fs_base 或升级 gdb
rdmsr 命令找不到未安装 msr-tools 或未加载 msr 模块apt install msr-tools; sudo modprobe msr

一句话总结 ​

观测段管理的最佳工具是 gdb 的 info registers：实测用户态 CS=0x33（GDT[6]、RPL=3）、SS=0x2b（GDT[5]）、DS/ES/FS/GS=0x0（长模式不检查基址/界限，选 NULL 也无妨）、fs_base=0x7ffff7dd4740（glibc 设的 TLS 基址）——与理论预测逐项吻合，fs_base/gs_base 是隐藏的 MSR 需要显式查看；GDT 内容可用 /sys/kernel/debug/x86/gdt 或 rdmsr 0xC0000081（MSR_STAR）查看；验证段权限最直接的方法是写一段 mov ds, 0x18 的内联汇编，用户态下必然 #GP(0) → SIGSEGV 崩溃——这是 max(CPL,RPL) > DPL 检查公式的现场证明；进阶可用 bpftrace 观测 syscall 进出时 CS 在 0x10/0x33 间的硬件跳变，用 gdb 多线程 print $fs_base 排查 TLS 串台。