6

Why do the data segment registers (ds/es/fs/gs) always seem to show up as 0x0 in GDB? For example, no matter what process or thread I look at, "info reg" always seems to give me output like this:

cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

I am trying to debug glibc code where I see the fs segment prefix in the functions I am dissembling:

(gdb) disas __lll_lock_wait
Dump of assembler code for function __lll_lock_wait:
0x000000302800e240 <+0>:     push   %r10
0x000000302800e242 <+2>:     push   %rdx
0x000000302800e243 <+3>:     xor    %r10,%r10
0x000000302800e246 <+6>:     mov    $0x2,%edx
0x000000302800e24b <+11>:    xor    $0x80,%esi
0x000000302800e251 <+17>:    and    %fs:0x48,%esi
0x000000302800e259 <+25>:    cmp    %edx,%eax
0x000000302800e25b <+27>:    jne    0x302800e264 <__lll_lock_wait+36>
0x000000302800e25d <+29>:    mov    $0xca,%eax

I know that this is how glibc will reference the thread's TCB (tcbhead_t) for TLS and other important stuff. So wouldn't that mean that each thread would need to have a unique descriptor entry? Shouldn't each thread have a unique value for the fs register? I do not even believe 0x0 is a valid selector at all because the TI (table indicator) bit would indicate the GDT, and I thought there is no valid 0 GDT entry.

I know I must be missing something obvious, anyone know what it is?

Environment: CentOS 6.6, x86_64

isamu
  • 61
  • 2

3 Answers3

3

Shouldn't each thread have a unique value for the fs register?

No, each thread needs a unique FS segment base, but instead of requiring an LDT or GDT entry for each possible base, there's a mechanism for the kernel to simply set the FS base address directly in the internal segment descriptor without using a slower mov fs, eax instruction that loads a whole segment description including permissions and stuff.

The standard mechanism was writing an MSR (model-specific register); See Detail about MSR_GS_BASE in linux x86 64.

Intel since IvyBridge has supported the FSGSBASE feature, but apparently Linux is only just recently taking advantage of the wrfsbase instruction, which is faster than the WRMSR method. See https://lwn.net/Articles/769355/.

As well as being faster than wrmsr, wrfsbase has the added feature that the kernel can let user-space execute it, so VMs in user-space (like Java) could maybe take advantage instead of needing to make a system call for an always-privileged WRMSR instruction.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
1

So wouldn't that mean that each thread would need to have a unique descriptor entry?

Yes.

Shouldn't each thread have a unique value for the fs register?

No. The value of fs register is the same, but the memory it points to is different in every thread. See arch_prctl(2) man page and code for setting this up in GLIBC source.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
1

I think it's done by kernel: Check the function start_thread_common(), then you will find the following:

    loadsegment(fs, 0); 
    loadsegment(es, _ds);
    loadsegment(ds, _ds);
    load_gs_index(0);

For x86 64, _ds is 0. Why _ds is 0, since it's completely useless. The following is from Intel SDM v3.

3.2.4 Segmentation in IA-32e Mode

In IA-32e mode of Intel 64 architecture, the effects of segmentation depend on whether the processor is running in compatibility mode or 64-bit mode. In compatibility mode, segmentation functions just as it does using legacy 16-bit or 32-bit protected mode semantics. In 64-bit mode, segmentation is generally (but not completely) disabled, creating a flat 64-bit linear-address space. The processor treats the segment base of CS, DS, ES, SS as zero, creating a linear address that is equal to the effective address. The FS and GS segments are exceptions. These segment registers (which hold the segment base) can be used as additional base registers in linear address calculations. They facilitate addressing local data and certain operating system data structures.

firo
  • 1,002
  • 12
  • 20