底层段寄存器的线程本地实际使用

Question

我阅读了许多文章和 S/O 答案说（在 linux x86_64 上）FS（或某些变体中的 GS）引用了一个特定于线程的页表条目，然后它给出了一个指向可共享的实际数据的指针数组数据。当线程被交换时，所有的寄存器都被切换，因此线程基页会发生变化。线程变量通过名称访问，只需要 1 个额外的指针跃点，并且引用的值可以共享给其他线程。一切都好，说得通。

事实上，如果你查看__errno_location(void)背后的函数的代码errno，你会发现类似的东西（这是来自 musl，但 gnu 并没有太大的不同）：

static inline struct pthread *__pthread_self()
{
    struct pthread *self;
    __asm__ __volatile__ ("mov %%fs:0,%0" : "=r" (self) );
    return self;
}

来自 glibc：

=> 0x7ffff6efb4c0 <__errno_location>:   endbr64
   0x7ffff6efb4c4 <__errno_location+4>: mov    0x6add(%rip),%rax        # 0x7ffff6f01fa8
   0x7ffff6efb4cb <__errno_location+11>:        add    %fs:0x0,%rax
   0x7ffff6efb4d4 <__errno_location+20>:        retq

所以我的期望是 FS 的实际值会因每个线程而改变。例如，在调试器下， gdb: info regor p $fs，我会看到 FS 的值在不同的线程中是不同的，但没有： ds, es, fs, gs 一直都为零。

在我自己的代码中，我写了类似下面的内容并得到相同的结果 - FS 没有改变，但 TLV “有效”：

struct Segregs
{
    unsigned short int  cs, ss, ds, es, fs, gs;
    friend std::ostream& operator << (std::ostream& str, const Segregs& sr)
    {
        str << "[cs:" << sr.cs << ",ss:" << sr.ss << ",ds:" << sr.ds
            << ",es:" << sr.es << ",fs:" << sr.fs << ",gs:" << sr.gs << "]";
        return str;
    }
};

Segregs GetSegRegs()
{
    unsigned short int  r_cs, r_ss, r_ds, r_es, r_fs, r_gs;
    __asm__ __volatile__ ("mov %%cs,%0" : "=r" (r_cs) );
    __asm__ __volatile__ ("mov %%ss,%0" : "=r" (r_ss) );
    __asm__ __volatile__ ("mov %%ds,%0" : "=r" (r_ds) );
    __asm__ __volatile__ ("mov %%es,%0" : "=r" (r_es) );
    __asm__ __volatile__ ("mov %%fs,%0" : "=r" (r_fs) );
    __asm__ __volatile__ ("mov %%gs,%0" : "=r" (r_gs) );
    return {r_cs, r_ss, r_ds, r_es, r_fs, r_gs};
}

但是输出呢？

Main: Seg regs : [cs:51,ss:43,ds:0,es:0,fs:0,gs:0]
Main:    tls    @0x7ffff699307c=0
Main:    static @0x96996c=0
 Modified to 1234
Main:    tls    @0x7ffff699307c=1234
Main:    static @0x96996c=1234

 Async thread
[New Thread 0x7ffff695e700 (LWP 3335119)]
Thread: Seg regs : [cs:51,ss:43,ds:0,es:0,fs:0,gs:0]
Thread:  tls    @0x7ffff695e6fc=0
Thread:  static @0x96996c=1234

那么实际上还有其他事情发生吗？发生了什么额外的诡计，为什么要增加复杂性？

对于上下文，我正在尝试做一些“用叉子时髦”的事情，所以我想知道血腥的细节。

Answer 1

在 64 位模式下，16 位 FS 和 GS 段寄存器的实际内容通常是“空选择器”( 0)，因为其他机制用于使用 64 位值设置段基址。（MSR 或wrfsbase）

与保护模式一样，CPU 内有单独的“FSBASE”和“GSBASE”寄存器，当您指定指令的 FS 段覆盖时，FSBASE 寄存器中的基地址将添加到操作数的有效地址中确定要访问的实际线性地址。

每个线程的内核上下文结构都存储其 FSBASE 和 GSBASE 寄存器的副本，并且它们会在每次上下文切换时适当地重新加载。

因此，实际发生的情况是每个线程将其 FSBASE 寄存器设置为指向其自己的线程本地存储。（根据 CPU 功能和操作系统设计，这可能仅适用于特权代码，因此可能需要系统调用。）然后可以使用具有 FS 段覆盖的指令来访问线程中具有给定偏移量的对象 -本地存储块，如您所见。

另一方面，在 32 位模式下，FS 和 GS 中的值确实具有更多含义；它们是段选择器，用于索引内核维护的描述符表。描述符表保存实际的段信息，包括其基地址，您可以使用系统调用来要求内核修改它。每个线程都有自己的本地描述符表，因此您不一定会在 FS 中看到不同线程的不同选择器，但来自不同线程的 FS 覆盖指令仍然会导致对不同线性地址的访问。

（或者 32 位内核可以写入 GDT 条目和mov寄存器中的常量fs，或者gs让它重新加载新写入的 GDT 条目。因此，每个逻辑核心只需要一个 GDT，而不是每个进程一个 LDT。 CPU 永远不会自行重新加载段描述符，尽管对于每核心 GDT，如果您有单独的 FS 和 GS 条目，该条目仍然会与当前任务匹配。因此用户空间可能不会用mov eax,gs/破坏自身mov gs,eax。）

不管怎样，这实际上只是缺乏一个方便的 MSR 或wrfsbase方法来设置段寄存器基址与mov Sreg, r/m触发 CPU 加载描述符分开。在保护模式或长模式下，段寄存器中的值确实需要有效（包括 null = 0），并且将一些随机值移入其中可能会出现错误。