5. 核心級異常處理¶
Joerg Pommnitz <joerg@raleigh.ibm.com> 的評論
當程序在核心模式下執行時，它經常需要訪問使用者模式記憶體，該記憶體的地址由不受信任的程式傳遞。 為了保護自己，核心必須驗證此地址。
在舊版本的 Linux 中，這是透過 int verify_area(int type, const void * addr, unsigned long size) 函式完成的（該函式此後已被 access_ok() 替換）。
此函式驗證了從地址“addr”開始，大小為“size”的記憶體區域是否可用於型別中指定的操作（讀取或寫入）。 為此，verify_read 必須查詢包含地址 addr 的虛擬記憶體區域 (vma)。 在正常情況下（正確工作的程式），此測試成功。 它僅對一些有錯誤的程式失敗。 在某些核心分析測試中，這種通常不需要的驗證佔用了相當多的時間。
為了克服這種情況，Linus 決定讓每個支援 Linux 的 CPU 中存在的虛擬記憶體硬體處理此測試。
這是如何工作的？
每當核心嘗試訪問當前無法訪問的地址時，CPU 都會生成頁面錯誤異常並呼叫頁面錯誤處理程式
void exc_page_fault(struct pt_regs *regs, unsigned long error_code)
在 arch/x86/mm/fault.c 中。 堆疊上的引數由 arch/x86/entry/entry_32.S 中的低階彙編粘合程式碼設定。 引數 regs 是指向堆疊上儲存的暫存器的指標，error_code 包含異常的原因程式碼。
exc_page_fault() 首先從 CPU 控制暫存器 CR2 獲取無法訪問的地址。 如果該地址位於程序的虛擬地址空間內，則可能發生故障，因為該頁未被交換，防寫或類似情況。 但是，我們對另一種情況感興趣：該地址無效，沒有包含該地址的 vma。 在這種情況下，核心跳轉到 bad_area 標籤。
在那裡，它使用導致異常的指令的地址（即 regs->eip）來查詢可以繼續執行的地址 (fixup)。 如果此搜尋成功，則故障處理程式會修改返回地址（再次 regs->eip）並返回。 執行將在 fixup 中的地址處繼續。
fixup 指向哪裡？
由於我們跳轉到 fixup 的內容，因此 fixup 顯然指向可執行程式碼。 此程式碼隱藏在使用者訪問宏中。 我選擇了在 arch/x86/include/asm/uaccess.h 中定義的 get_user() 宏作為示例。 定義有點難以理解，所以讓我們看看預處理器和編譯器生成的程式碼。 我選擇了 drivers/char/sysrq.c 中的 get_user() 呼叫進行詳細檢查。
sysrq.c 第 587 行中的原始程式碼
get_user(c, buf);
預處理器輸出（已編輯為可讀）
(
{
long __gu_err = - 14 , __gu_val = 0;
const __typeof__(*( ( buf ) )) *__gu_addr = ((buf));
if (((((0 + current_set[0])->tss.segment) == 0x18 ) ||
(((sizeof(*(buf))) <= 0xC0000000UL) &&
((unsigned long)(__gu_addr ) <= 0xC0000000UL - (sizeof(*(buf)))))))
do {
__gu_err = 0;
switch ((sizeof(*(buf)))) {
case 1:
__asm__ __volatile__(
"1: mov" "b" " %2,%" "b" "1\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %3,%0\n"
" xor" "b" " %" "b" "1,%" "b" "1\n"
" jmp 2b\n"
".section __ex_table,\"a\"\n"
" .align 4\n"
" .long 1b,3b\n"
".text" : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *)
( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err )) ;
break;
case 2:
__asm__ __volatile__(
"1: mov" "w" " %2,%" "w" "1\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %3,%0\n"
" xor" "w" " %" "w" "1,%" "w" "1\n"
" jmp 2b\n"
".section __ex_table,\"a\"\n"
" .align 4\n"
" .long 1b,3b\n"
".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
( __gu_addr )) ), "i"(- 14 ), "0"( __gu_err ));
break;
case 4:
__asm__ __volatile__(
"1: mov" "l" " %2,%" "" "1\n"
"2:\n"
".section .fixup,\"ax\"\n"
"3: movl %3,%0\n"
" xor" "l" " %" "" "1,%" "" "1\n"
" jmp 2b\n"
".section __ex_table,\"a\"\n"
" .align 4\n" " .long 1b,3b\n"
".text" : "=r"(__gu_err), "=r" (__gu_val) : "m"((*(struct __large_struct *)
( __gu_addr )) ), "i"(- 14 ), "0"(__gu_err));
break;
default:
(__gu_val) = __get_user_bad();
}
} while (0) ;
((c)) = (__typeof__(*((buf))))__gu_val;
__gu_err;
}
);
哇！ 黑色GCC/彙編魔法。 這不可能理解，所以讓我們看看 gcc 生成什麼程式碼
> xorl %edx,%edx
> movl current_set,%eax
> cmpl $24,788(%eax)
> je .L1424
> cmpl $-1073741825,64(%esp)
> ja .L1423
> .L1424:
> movl %edx,%eax
> movl 64(%esp),%ebx
> #APP
> 1: movb (%ebx),%dl /* this is the actual user access */
> 2:
> .section .fixup,"ax"
> 3: movl $-14,%eax
> xorb %dl,%dl
> jmp 2b
> .section __ex_table,"a"
> .align 4
> .long 1b,3b
> .text
> #NO_APP
> .L1423:
> movzbl %dl,%esi
最佳化器做得很好，給了我們一些我們可以理解的東西。 我們可以嗎？ 實際的使用者訪問非常明顯。 由於統一的地址空間，我們可以直接訪問使用者記憶體中的地址。 但是 .section stuff 做什麼?????
要理解這一點，我們必須檢視最終核心
> objdump --section-headers vmlinux
>
> vmlinux: file format elf32-i386
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text 00098f40 c0100000 c0100000 00001000 2**4
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 1 .fixup 000016bc c0198f40 c0198f40 00099f40 2**0
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 2 .rodata 0000f127 c019a5fc c019a5fc 0009b5fc 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 3 __ex_table 000015c0 c01a9724 c01a9724 000aa724 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 4 .data 0000ea58 c01abcf0 c01abcf0 000abcf0 2**4
> CONTENTS, ALLOC, LOAD, DATA
> 5 .bss 00018e21 c01ba748 c01ba748 000ba748 2**2
> ALLOC
> 6 .comment 00000ec4 00000000 00000000 000ba748 2**0
> CONTENTS, READONLY
> 7 .note 00001068 00000ec4 00000ec4 000bb60c 2**0
> CONTENTS, READONLY
在生成的物件檔案中顯然有 2 個非標準 ELF 節。 但首先，我們想知道我們的程式碼在最終核心可執行檔案中發生了什麼
> objdump --disassemble --section=.text vmlinux
>
> c017e785 <do_con_write+c1> xorl %edx,%edx
> c017e787 <do_con_write+c3> movl 0xc01c7bec,%eax
> c017e78c <do_con_write+c8> cmpl $0x18,0x314(%eax)
> c017e793 <do_con_write+cf> je c017e79f <do_con_write+db>
> c017e795 <do_con_write+d1> cmpl $0xbfffffff,0x40(%esp,1)
> c017e79d <do_con_write+d9> ja c017e7a7 <do_con_write+e3>
> c017e79f <do_con_write+db> movl %edx,%eax
> c017e7a1 <do_con_write+dd> movl 0x40(%esp,1),%ebx
> c017e7a5 <do_con_write+e1> movb (%ebx),%dl
> c017e7a7 <do_con_write+e3> movzbl %dl,%esi
整個使用者記憶體訪問減少到 10 條 x86 機器指令。 .section 指令中包含的指令不再位於正常的執行路徑中。 它們位於可執行檔案的不同部分
> objdump --disassemble --section=.fixup vmlinux
>
> c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
> c0199ffa <.fixup+10ba> xorb %dl,%dl
> c0199ffc <.fixup+10bc> jmp c017e7a7 <do_con_write+e3>
最後
> objdump --full-contents --section=__ex_table vmlinux
>
> c01aa7c4 93c017c0 e09f19c0 97c017c0 99c017c0 ................
> c01aa7d4 f6c217c0 e99f19c0 a5e717c0 f59f19c0 ................
> c01aa7e4 080a18c0 01a019c0 0a0a18c0 04a019c0 ................
或以人類可讀的位元組順序
> c01aa7c4 c017c093 c0199fe0 c017c097 c017c099 ................
> c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
^^^^^^^^^^^^^^^^^
this is the interesting part!
> c01aa7e4 c0180a08 c019a001 c0180a0a c019a004 ................
發生了什麼？ 彙編指令
.section .fixup,"ax"
.section __ex_table,"a"
告訴彙編器將以下程式碼移動到 ELF 物件檔案中的指定節。 所以這些指令
3: movl $-14,%eax
xorb %dl,%dl
jmp 2b
最終位於物件檔案的 .fixup 節中，並且地址
.long 1b,3b
最終位於物件檔案的 __ex_table 節中。 1b 和 3b 是本地標籤。 本地標籤 1b（1b 代表下一個標籤 1 向後）是可能發生故障的指令的地址，即在本例中，標籤 1 的地址是 c017e7a5：原始彙編程式碼：> 1: movb (%ebx),%dl 並且連結在 vmlinux 中：> c017e7a5 <do_con_write+e1> movb (%ebx),%dl
本地標籤 3（再次向後）是處理故障的程式碼的地址，在本例中，實際值是 c0199ff5：原始彙編程式碼：> 3: movl $-14,%eax 並且連結在 vmlinux 中：> c0199ff5 <.fixup+10b5> movl $0xfffffff2,%eax
如果 fixup 能夠處理異常，則控制流可能會返回到觸發故障的指令之後的指令，即本地標籤 2b。
彙編程式碼
> .section __ex_table,"a"
> .align 4
> .long 1b,3b
變為值對
> c01aa7d4 c017c2f6 c0199fe9 c017e7a5 c0199ff5 ................
^this is ^this is
1b 3b
核心異常表中的 c017e7a5,c0199ff5。
那麼，如果來自核心模式的故障沒有合適的 vma 會發生什麼？
訪問無效地址
> c017e7a5 <do_con_write+e1> movb (%ebx),%dl
MMU 生成異常
CPU 呼叫 exc_page_fault()
exc_page_fault() 呼叫 do_user_addr_fault()
do_user_addr_fault() 呼叫 kernelmode_fixup_or_oops()
kernelmode_fixup_or_oops() 呼叫 fixup_exception() (regs->eip == c017e7a5);
fixup_exception() 呼叫 search_exception_tables()
search_exception_tables() 在異常表（即 ELF 節 __ex_table 的內容）中查詢地址 c017e7a5，並返回關聯的故障處理程式碼 c0199ff5 的地址。
fixup_exception() 修改其自己的返回地址以指向故障處理程式碼並返回。
執行在故障處理程式碼中繼續。
EAX 變為 -EFAULT (== -14)
DL 變為零（我們從使用者空間“讀取”的值）
執行在本地標籤 2（緊接在發生故障的使用者訪問之後的指令的地址）處繼續。
上面的步驟 a 到 c 在某種程度上模擬了發生故障的指令。
這就是全部，大部分。 如果您檢視我們的示例，您可能會問為什麼我們在異常處理程式程式碼中將 EAX 設定為 -EFAULT。 好吧，如果使用者訪問成功，get_user() 宏實際上返回一個值：0，如果失敗則返回 -EFAULT。 我們的原始程式碼沒有測試此返回值，但是 get_user() 中的內聯彙編程式碼嘗試返回 -EFAULT。 GCC 選擇 EAX 來返回此值。
注意：由於構建異常表的方式以及需要排序的方式，僅對 .text 節中的程式碼使用異常。 任何其他節都會導致異常表無法正確排序，並且異常將失敗。
當向 x86 Linux 新增 64 位支援時，情況發生了變化。 不是透過將兩個條目從 32 位擴充套件到 64 位來使異常表的大小加倍，而是使用了一個巧妙的技巧將地址儲存為相對於表本身的偏移量。 彙編程式碼從
.long 1b,3b
to:
.long (from) - .
.long (to) - .
使用這些值的 C 程式碼轉換回絕對地址，如下所示
ex_insn_addr(const struct exception_table_entry *x)
{
return (unsigned long)&x->insn + x->insn;
}
在 v4.6 中，異常表條目擴充套件了一個新欄位“handler”。 這也是 32 位寬，包含第三個相對函式指標，該指標指向以下函式之一
int ex_handler_default(const struct exception_table_entry *fixup)這是僅跳轉到 fixup 程式碼的遺留案例
int ex_handler_fault(const struct exception_table_entry *fixup)這種情況提供了在 entry->insn 處發生的陷阱的故障編號。 它用於區分頁面錯誤和機器檢查。
可以輕鬆新增更多功能。
CONFIG_BUILDTIME_TABLE_SORT 允許透過主機實用程式 scripts/sorttable 在核心映像的連結後對 __ex_table 節進行排序。 它會將符號 main_extable_sort_needed 設定為 0，從而避免在啟動時對 __ex_table 節進行排序。 透過對異常表進行排序，在執行時發生異常時，我們可以透過二進位制搜尋快速查詢 __ex_table 條目。
這不僅僅是啟動時間最佳化，某些架構需要對該表進行排序才能在啟動過程的相對早期處理異常。 例如，i386 在啟用分頁支援之前就使用了這種形式的異常處理！