Use of gs register on a 32 bit program over a 64 bit linux

Question

In a 64 bit program the selector:offset used to get the stack protector is fs:0x28, where fs=0. This poses no problem because in 64 bit we have the MSR fs_base (which is set to point to the TLS) and the GDT is completely ignored. But with 32 bit program the stack protector is read from gs:0x14. Running over a 64

Accepted Answer

After the comment of @PeterCordes I searched in the &#8220;AMD64 Architecture Programmer&#8217;s Manual, vol. 2&#8221;, where in page 27 says:Compatibility mode ignores the high 32 bits of base address in the FS and GS segment descriptors when calculating an effective address.This implies that a 64-bit kernel managing a 32-bit process uses the MSR_*S_BASE registers as it would for a 64-bit process.  The kernel can set the segment bases normally while in 64-bit long mode, so it doesn&#8217;t matter whether or not those MSRs are available in 32-bit compatibility sub-mode of long mode, or in pure 32-bit protected mode (legacy mode, 32-bit kernel).  A 64-bit Linux kernel only uses compat mode for ring 3 (user-space) where wrmsr and rdmsr aren&#8217;t available because of privileges.  As always, segment-base settings persist across changes to privilege level, like returning to user-space with sysret or iret.Another thing that made me think that this registers weren&#8217;t used for compatibility-mode processes was GDB. This is what happens when trying to print this register while debugging a 32-bit program.:(gdb) i r $gs_baseInvalid register `gs_base'Debugging a 64-bit program it works fine.(gdb) i r $fs_basefs_base        0x7ffff7d00c00      0x7ffff7d00c00Since the instruction rdgsbase is a 64-bit instruction (trying to execute that opcode in a program 32-bit yields a SIGILL signal), it is a bit tricky to obtain the value of this registers within a 32-bit program.The first solution I thought was to read it from a kernel module:unsigned long gs_base = 0xdeadbeefc0ffee13;asm("swapgs;"    "rdgsbase %0;"    // maybe unsafe if an interrupt happens here                      // be careful if using this for anything more than toy experiments.    "swapgs;"    : "=r"(gs_base));printk("gs_base: 0x%016lx", gs_base);So I created a driver for a device in /dev, so when a program open()s that file the code above is executed. After compiling and running a 32-bit program that opens this file I got this[10793.682033] gs_base: 0x00000000f7f9f040And using gdb to inspect 0xf7f9f040+0x14 I saw the canary, meaning that it was the TLS.(gdb) x/wx 0xf7f9f040+0x140xf7f9f054: 0x21f03c00(gdb) x/wx $ebp-0xc0xbffff60c: 0x21f03c00The other way I can think of is to perform a far call to change from 32-bit to 64-bit, execute rdgsbase and then return to 64-bit. Probably this is a better solution since it doesn&#8217;t need a kernel module.  (As long as you can assume you&#8217;re running on a CPU that supports the FSGSBASE extension, and a new enough kernel to enable it.)Something like this:#include <stdio.h>__attribute__((naked))   // or define the function in an asm statement at global scopeextern void rdgsbase(){    asm("rdgsbase %eax; retf");}int main(){    unsigned int* gs_base = NULL;    unsigned int canary;    // would be unsafe in a leaf function: clobbers the red zone    asm("lcall $0x33, $rdgsbase; mov %%eax, %0" : "=m"(gs_base) : : "eax");    asm("mov %%gs:0x14, %%eax ; mov %%eax, %0" : "=m"(canary) : : "eax");    printf("gs_base = %pn", gs_base);    printf("canary: 0x%08xn", canary);    printf("canary: 0x%08xn", gs_base[5]);}I know it is very very dirty and ugly, but it works.$ gcc gs_base.c -o gs_base -m32/usr/bin/ld: /tmp/ccAPoxwj.o: warning: relocation against `rdgsbase' in read-only section `.text'/usr/bin/ld: warning: creating DT_TEXTREL in a PIE$ ./gs_base gs_base = 0xf7f80040canary: 0x59511d00canary: 0x59511d00In a 32-bit system the gs segment selector has the value 0x33, this points to the 7th entry in the GDT (index 6). So let&#8217;s see what is in there.Using the same module I shown in the OP (with only minor modifications) I printed the GDT used during the execution of a specific process. This is the entry with index 6:[ 3579.535005] Entry #6:[ 3579.535007]  Raw: 0xd100ffff[ 3579.535009]  Base: 0xb7fcd100[ 3579.535011]  Limit: 0xfffff[ 3579.535013]  Flags: 0xd0f3[ 3579.535018]      Type = 0x3 (Data, expand down, writable, accessed)[ 3579.535019]      S    = 0 (user)[ 3579.535021]      DPL  = 3[ 3579.535023]      P    = 1 (present)[ 3579.535025]      AVL  = 1[ 3579.535027]      L    = 0[ 3579.535028]      D/B  = 1[ 3579.535030]      G    = 1 (KiB)In gdb we can verify that it coincides with the TLS of said process:(gdb) x/wx $ebp-0xc0xbffff60c: 0xa6e29800(gdb) x/wx 0xb7fcd100+0x140xb7fcd114: 0xa6e29800Using strace we can see how the 32-bit glibc sets the gs on a 64-bit system:set_thread_area({entry_number=-1, base_addr=0xf7ebb040, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=12)This syscall performs in the kernel the setup of the MSR_GS_BASE with the value specified in the argument base_addr. The kernel also places the value 0x63 in the gs register, which points to the entry with index 12, a NULL entry.On a 32-bit system the syscall is exactly the sameset_thread_area({entry_number=-1, base_addr=0xb7f66100, limit=0x0fffff, seg_32bit=1, contents=0, read_exec_only=0, limit_in_pages=1, seg_not_present=0, useable=1}) = 0 (entry_number=6)But here, on a 32-bit kernel (which doesn&#8217;t know anything about MSR_GS_BASE) the gs register gets the value 0x33, pointing to the index 6 in the GDT. Since there is no MSR_GS_BASE now is the GDT entry the one that is setup, with base address and limit fields (and rest of fields) equal to the ones specified in the arguments.On the other hand, the 64-bit glibc uses the syscall arch_prctl(ARCH_SET_FS, 0x...) to set the value of MSR_FS_BASE. This syscall is only available for 64-bit programs.The only thing that I don&#8217;t quite understand yet is why set gs=0x63 instead of 0 or 0x2b (the value of ss, ds and es)&#8230;

Advertisement

Answer