Why does this memory address %fs:0x28 ( fs[0x28] ) have a random value?

Question

I've written a piece of C code and I've disassembled it as well as read the registers to understand how the program works in assembly.

int test(char *this){
    char sum_buf[6];
    strncpy(sum_buf,this,32);
    return 0;
}

The piece of my code that I've been examining is the test function. When I disassemble the output my test function I get ...

   0x00000000004005c0 <+12>:        mov    %fs:0x28,%rax
=> 0x00000000004005c9 <+21>:        mov    %rax,-0x8(%rbp)
... stuff ..
   0x00000000004005f0 <+60>:        xor    %fs:0x28,%rdx
   0x00000000004005f9 <+69>:        je     0x400600 <test+76>
   0x00000000004005fb <+71>:        callq  0x4004a0 <__stack_chk_fail@plt>
   0x0000000000400600 <+76>:        leaveq 
   0x0000000000400601 <+77>:        retq 

What I would like to know is what mov %fs:0x28,%rax is really doing?

Oram

Related: https://mcmap.net/q/24772/-stack-smashing-detected – Shepp

Answer 1

Both the FS and GS registers can be used as base-pointer addresses in order to access special operating system data-structures. So what you're seeing is a value loaded at an offset from the value held in the FS register, and not bit manipulation of the contents of the FS register.

Specifically what's taking place, is that FS:0x28 on Linux is storing a special sentinel stack-guard value, and the code is performing a stack-guard check. For instance, if you look further in your code, you'll see that the value at FS:0x28 is stored on the stack, and then the contents of the stack are recalled and an XOR is performed with the original value at FS:0x28. If the two values are equal, which means that the zero-bit has been set because XOR'ing two of the same values results in a zero-value, then we jump to the test routine, otherwise we jump to a special function that indicates that the stack was somehow corrupted, and the sentinel value stored on the stack was changed.

If using GCC, this can be disabled with:

-fno-stack-protector

Urinary

Ok, that makes sense. How could I read this address and value with gdb? – Oram

The simplest way is to look at the contents of the RAX register directly after the MOV operation. – Urinary

segmented addressing is no longer used — this is not true, the segmented addressing is still used 100%, although the usage shifted dramatically to become a virtual space instead of a segment. Since we can address the entire memory with a single register in 64 bits (although in most cases only 48 are used), we do not modify those registers, but they are really important in link with the MMU and memory protection schemes. – Laity

Hey, i know this is really old but I just wanted to ask why does %fs:0x28 have to go through rax and then get added to the stack? Why can't we directly just add it like mov %fs:0x28, -0x8(%rbp)? – Deidradeidre

@need_to_know_now: That would be a memory-to-memory move, and x86 doesn't have any such instruction. Try assembling it and you'll get an error. If you want to move memory to memory, you have to load into a register and then store with a second instruction. – Pestle

Answer 2

glibc:
  uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (_dl_random);
# ifdef THREAD_SET_STACK_GUARD
  THREAD_SET_STACK_GUARD (stack_chk_guard); 

the _dl_random from kernel.

Zarf

Answer 3

Looking at http://www.imada.sdu.dk/Courses/DM18/Litteratur/IntelnATT.htm, I think %fs:28 is actually an offset of 28 bytes from the address in %fs. So I think it's loading a full register size from location %fs + 28 into %rax.

Karlene

This is just not correct. fs is not a "normal" register. It is a segment register. In protected mode, fs is a selector into the GDT. There are hidden "base" and "limit" registers associated with it, that you cannot see. So fs:0x28 is really [hidden_fs_base + 0x28]. – Are