堆棧內存溢出
  簡體   English   中英

在 64 位 linux 上的 32 位程序上使用 gs 寄存器

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

 原文  2021-12-10 13:55:53  6   1    linux/ assembly/ x86/ memory-segmentation/ gdt

問題描述

在 64 位程序中，用於獲取堆棧保護器的選擇器：偏移量是 fs:0x28，其中 fs=0。 這沒有問題，因為在 64 位中我們有 MSR fs_base（設置為指向 TLS）並且 GDT 被完全忽略。

但是對於 32 位程序，堆棧保護器是從 gs:0x14 讀取的。 在 64 位系統上運行我們有 gs=0x63，在 32 位系統上 gs=0x33。 這里沒有 MSR，因為它們是在 x86_64 中引入的，因此 GDT 在這里起着重要作用。

剖析這個值，我們在兩種情況下都得到了 DPL=3（這是預期的），描述符表選擇器指示 GDT（Linux 中不使用 LDT），選擇器指向索引 12 表示 64 位和索引 6 表示 32 的條目位。

使用 kernel 模塊，我能夠檢查 64 位 linux 中的此條目是否為 NULL。 所以我不明白TLS的地址是如何解析的。

kernel模塊的相關部分如下：

void gdtread()
{
    struct desc_ptr gdtr;
    seg_descriptor* gdt_entry = NULL;
    uint16_t tr;
    int i;

    asm("str %0" : "=m"(tr));

    native_store_gdt(&gdtr); // equiv. to asm("sgdt %0" : "=m"(gdtr));
    printk("GDT address: 0x%px, GDT size: %d bytes = %i entries\n",
           (void*)gdtr.address, gdtr.size + 1, (gdtr.size + 1) / 8);

    gdt_entry = (seg_descriptor*)gdtr.address;
    for(i = 0; i < (gdtr.size + 1) / 8; i++)
    {
        if(tr >> 3 == i)
            printk("Entry #%i:\t<--- TSS (RPL = %i)", i, tr & 3);
        else
            printk("Entry #%i:", i);

        if(!((uint64_t*)gdt_entry)[i])
        {
            printk("\tNULL");
            continue;
        }
        
        if(gdt_entry[i].s)
            user_segment_desc(&gdt_entry[i]);
        else
            system_segment_desc((sys_seg_descriptor*)&gdt_entry[i++]);
    }
}

在 64 位系統上輸出以下內容：

[ 3817.191065] GDT address: 0xfffffe0000001000, GDT size: 128 bytes = 16 entries
[ 3817.191073] Entry #0:
[ 3817.191075]  NULL
[ 3817.191078] Entry #1:
[ 3817.191081]  Raw: 0x00cf9b000000ffff
[ 3817.191084]  Base: 0x00000000
[ 3817.191088]  Limit: 0xfffff
[ 3817.191091]  Flags: 0xc09b
[ 3817.191096]      Type = 0xb (Code, non conforming, readable, accessed)
[ 3817.191100]      S    = 0 (user)
[ 3817.191103]      DPL  = 0
[ 3817.191105]      P    = 1 (present)
[ 3817.191109]      AVL  = 0
[ 3817.191112]      L    = 0 (legacy mode)
[ 3817.191115]      D/B  = 1
[ 3817.191118]      G    = 1 (KiB)
[ 3817.191121] Entry #2:
[ 3817.191124]  Raw: 0x00af9b000000ffff
[ 3817.191127]  Base: 0x00000000
[ 3817.191130]  Limit: 0xfffff
[ 3817.191133]  Flags: 0xa09b
[ 3817.191137]      Type = 0xb (Code, non conforming, readable, accessed)
[ 3817.191141]      S    = 0 (user)
[ 3817.191144]      DPL  = 0
[ 3817.191146]      P    = 1 (present)
[ 3817.191149]      AVL  = 0
[ 3817.191152]      L    = 1 (long mode)
[ 3817.191155]      D/B  = 0
[ 3817.191157]      G    = 1 (KiB)
[ 3817.191160] Entry #3:
[ 3817.191163]  Raw: 0x00cf93000000ffff
[ 3817.191166]  Base: 0x00000000
[ 3817.191169]  Limit: 0xfffff
[ 3817.191171]  Flags: 0xc093
[ 3817.191175]      Type = 0x3 (Data, expand down, writable, accessed)
[ 3817.191178]      S    = 0 (user)
[ 3817.191181]      DPL  = 0
[ 3817.191183]      P    = 1 (present)
[ 3817.191186]      AVL  = 0
[ 3817.191189]      L    = 0
[ 3817.191191]      D/B  = 1
[ 3817.191194]      G    = 1 (KiB)
[ 3817.191197] Entry #4:
[ 3817.191199]  Raw: 0x00cffb000000ffff
[ 3817.191202]  Base: 0x00000000
[ 3817.191205]  Limit: 0xfffff
[ 3817.191207]  Flags: 0xc0fb
[ 3817.191211]      Type = 0xb (Code, non conforming, readable, accessed)
[ 3817.191214]      S    = 0 (user)
[ 3817.191217]      DPL  = 3
[ 3817.191219]      P    = 1 (present)
[ 3817.191222]      AVL  = 0
[ 3817.191224]      L    = 0 (legacy mode)
[ 3817.191227]      D/B  = 1
[ 3817.191230]      G    = 1 (KiB)
[ 3817.191233] Entry #5:
[ 3817.191235]  Raw: 0x00cff3000000ffff
[ 3817.191238]  Base: 0x00000000
[ 3817.191241]  Limit: 0xfffff
[ 3817.191243]  Flags: 0xc0f3
[ 3817.191246]      Type = 0x3 (Data, expand down, writable, accessed)
[ 3817.191250]      S    = 0 (user)
[ 3817.191252]      DPL  = 3
[ 3817.191255]      P    = 1 (present)
[ 3817.191258]      AVL  = 0
[ 3817.191260]      L    = 0
[ 3817.191262]      D/B  = 1
[ 3817.191265]      G    = 1 (KiB)
[ 3817.191268] Entry #6:
[ 3817.191270]  Raw: 0x00affb000000ffff
[ 3817.191273]  Base: 0x00000000
[ 3817.191276]  Limit: 0xfffff
[ 3817.191278]  Flags: 0xa0fb
[ 3817.191281]      Type = 0xb (Code, non conforming, readable, accessed)
[ 3817.191284]      S    = 0 (user)
[ 3817.191287]      DPL  = 3
[ 3817.191289]      P    = 1 (present)
[ 3817.191292]      AVL  = 0
[ 3817.191295]      L    = 1 (long mode)
[ 3817.191298]      D/B  = 0
[ 3817.191300]      G    = 1 (KiB)
[ 3817.191303] Entry #7:
[ 3817.191306]  NULL
[ 3817.191308] Entry #8:    <--- TSS (RPL = 0)
[ 3817.191312]  Raw: 0x00000000fffffe0000008b0030004087
[ 3817.191316]  Base: 0xfffffe0000003000
[ 3817.191321]  Limit: 0x04087
[ 3817.191324]  Flags: 0x008b
[ 3817.191327]      Type = 0xb (Busy 64-bit TSS)
[ 3817.191331]      S    = 1 (system)
[ 3817.191333]      DPL  = 0
[ 3817.191336]      P    = 1 (present)
[ 3817.191339]      AVL  = 0
[ 3817.191341]      L    = 0
[ 3817.191344]      D/B  = 0
[ 3817.191347]      G    = 0 (B)
[ 3817.191349] Entry #10:
[ 3817.191352]  NULL
[ 3817.191355] Entry #11:
[ 3817.191358]  NULL
[ 3817.191360] Entry #12:
[ 3817.191362]  NULL
[ 3817.191365] Entry #13:
[ 3817.191367]  NULL
[ 3817.191369] Entry #14:
[ 3817.191372]  NULL
[ 3817.191374] Entry #15:
[ 3817.191377]  Raw: 0x0040f50000000000
[ 3817.191380]  Base: 0x00000000
[ 3817.191382]  Limit: 0x00000
[ 3817.191385]  Flags: 0x40f5
[ 3817.191389]      Type = 0x5 (Data, expand up, read only, accessed)
[ 3817.191392]      S    = 0 (user)
[ 3817.191395]      DPL  = 3
[ 3817.191397]      P    = 1 (present)
[ 3817.191400]      AVL  = 0
[ 3817.191403]      L    = 0
[ 3817.191405]      D/B  = 1
[ 3817.191408]      G    = 0 (B)

我還沒有在 32 位系統上嘗試過這個模塊，但我正在路上。

因此，為了明確問題：gs 段選擇器如何在 64 位 linux kernel 上運行的 32 位程序中工作？

1 個解決方案

解決方案1
 0  2021-12-10 20:39:15

在@PeterCordes 發表評論后，我在“AMD64 架構程序員手冊，第 2 卷”中進行了搜索，第 27 頁中說：

兼容模式在計算有效地址時會忽略 FS 和 GS 段描述符中基地址的高 32 位。

這意味着在 64 位系統上運行的 32 位進程像 64 位進程一樣使用 MSR_*S_BASE 寄存器，盡管 MSR_*S_BASE 寄存器在保護模式（32 位）中不存在 - 它們被添加到長模式（64 位），但它們也存在於兼容模式（32 位）中。

讓我覺得這個寄存器在兼容模式下不起作用的另一件事是 GDB。 這是在調試 32 位程序時嘗試打印此寄存器時發生的情況。：

(gdb) i r $gs_base
Invalid register `gs_base'

調試 64 位程序它工作正常。

(gdb) i r $fs_base
fs_base        0x7ffff7d00c00      0x7ffff7d00c00

由於rdgsbase指令是 64 位指令（嘗試在 32 位程序中執行該操作碼會產生 SIGILL 信號），因此在 32 位程序中獲取此寄存器的值有點棘手。

我認為的第一個解決方案是從 kernel 模塊中讀取它：

unsigned long gs_base = 0xdeadbeefc0ffee13;
asm("swapgs;"
    "rdgsbase %0;"
    "swapgs;"
    : "=r"(gs_base));
printk("gs_base: 0x%016lx", gs_base);

所以我在/dev中為一個設備創建了一個驅動程序，所以當一個程序open() s 該文件時，上面的代碼被執行。 編譯並運行打開此文件的 32 位程序后，我得到了這個

[10793.682033] gs_base: 0x00000000f7f9f040

並使用 gdb 檢查0xf7f9f040+0x14我看到了金絲雀，這意味着它是 TLS。

(gdb) x/wx 0xf7f9f040+0x14
0xf7f9f054: 0x21f03c00
(gdb) x/wx $ebp-0xc
0xbffff60c: 0x21f03c00

我能想到的另一種方法是執行遠調用以從 32 位更改為 64 位，執行 rdgsbase 然后返回到 64 位。 可能這是一個更好的解決方案，因為它不需要 kernel 模塊。 像這樣的東西：

#include <stdio.h>

extern void rdgsbase()
{
    asm("rdgsbase %eax; pop %ebp; retf");
}

int main()
{
    unsigned int* gs_base = NULL;
    unsigned int canary;
    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 = %p\n", gs_base);
    printf("canary: 0x%08x\n", canary);
    printf("canary: 0x%08x\n", gs_base[5]);
}

我知道它非常骯臟和丑陋，但它有效。

$ 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 = 0xf7f80040
canary: 0x59511d00
canary: 0x59511d00

在 32 位系統中， gs段選擇器的值為 0x33，它指向 GDT 中的第 7 個條目（索引 6）。 所以讓我們看看里面有什么。

使用我在 OP 中顯示的相同模塊（僅稍作修改），我打印了在執行特定進程期間使用的 GDT。 這是索引為 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)

在 gdb 中，我們可以看到它是否與所述進程的 TLS 一致：

(gdb) x/wx $ebp-0xc
0xbffff60c: 0xa6e29800
(gdb) x/wx 0xb7fcd100+0x14
0xb7fcd114: 0xa6e29800

使用strace我們可以看到 32 位 glibc 如何在 64 位系統上設置 gs：

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)

此系統調用在 kernel 中使用參數base_addr中指定的值執行 MSR_GS_BASE 的設置。 kernel 還將值 0x63 放在 gs 寄存器中，它指向索引為 12 的條目，即 NULL 條目。

在 32 位系統上，系統調用完全相同

set_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)

但是在這里，在 32 位 kernel（它對 MSR_GS_BASE 不了解）上，gs 寄存器的值是 0x33，指向 GDT 中的索引 6。 由於現在沒有 MSR_GS_BASE，因此設置了 GDT 條目，其基地址和限制字段（以及字段的 rest）等於 arguments 中指定的那些。

另一方面，64 位 glibc 使用系統調用arch_prctl(ARCH_SET_FS, 0x...)來設置 MSR_FS_BASE 的值。 此系統調用僅適用於 64 位程序。

唯一我還不太明白的是為什么設置 gs=0x63 而不是 0 或 0x2b（ss、ds 和 es 的值）...

暫無
暫無

聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

相關問題 在64位linux機器上靜態編譯32位程序 是否可以在64位Linux中使用相同的可執行文件中的64位和32位指令？ 在64位linux上安裝python 32位 iconv（）32位和Linux上的64位 在64位Linux上編譯32位應用程序 將Linux 32位應用程序移植到64位？ 將數據從32位用戶程序傳遞到64位Linux 如何在 32 位程序中使用 statfs64()？ 32位C程序不再在64位OS Linux上將char轉換為int Linux：從32位用戶模式程序中檢測64位內核（長模式）
相關標簽
 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM