這是參考CVE-2018-8897（與CVE-2018-1087有關），描述如下：在某些或所有操作系統內核的開發中，《英特爾64和IA-32體系結構軟件開發人員手冊》（SDM）的系統編程指南中的一條語句處理不當，導致MOV SS推遲的#DB異常的行為異常或POP SS，例如Windows，macOS，某些Xen配置或FreeBSD中的特權升級或Linux內核崩潰所證明的那樣。MOV到SS和POP SS指令禁止中斷（包括NMI），數據斷點和單步陷阱異常，直到下一條指令之后的指令邊界為止（SDM第3A卷； 6.8.3節）。（禁止的數據斷點是由MOV到SS或POP到SS指令本身訪問的存儲器上的斷點。）請注意，調試異常不受中斷允許（EFLAGS.IF）系統標志（SDM第3A卷；第2節，第1部分）的禁止。第2.3節）。如果MOV到SS或POP到SS指令之后的指令是SYSCALL，SYSENTER，INT 3等指令，該指令以CPL <3的方式將控制權轉移到操作系統，則在將調試轉移到CPL <3的情況下會傳遞調試異常。已經完成。OS內核可能不希望事件發生的順序如此，因此發生時可能會遇到意外的行為。在閱讀有關Linux內核的相關git commit時，我注意到該提交消息指出：x86 / entry / 64：請勿將IST條目用于#BP堆棧＃BP / int3沒有IST值得的。我們不允許kprobes出現在內核中少數以無效堆棧運行于CPL0的地方，而32位內核永遠將正常中斷門用于#BP。此外，在內核模式下，我們不允許將kprobes放在有userg的地方，因此“偏執狂”也是不必要的。鑒于該漏洞，我試圖了解提交消息中的最后一句話。我了解到，IST條目是指中斷堆棧表中的（據說）“已知良好”堆棧指針之一，該指針可用于處理中斷。我還了解到#BP指的是斷點異常（與等效INT3），而kprobes是調試機制，據稱該機制僅在環0（CPL0）特權級別的內核中運行。但是我在接下來的部分中完全迷失了，這可能是因為“ usergs”是一個拼寫錯誤，而我只是缺少了預期的內容：此外，在內核模式下，我們不允許將kprobes放在有userg的地方，因此“偏執狂”也是不必要的。這句話是什么意思？
1 回答
飲歌長嘯
TA貢獻1951條經驗 獲得超3個贊
usergs指的是x86-64 swapgs指令，該指令gs與內部保存的GS值交換給內核，以從syscall入口點查找內核堆棧。交換也交換緩存的gsbase段信息，而不是根據gs值本身從GDT重新加載。（wrgsbase可以獨立于GDT / LDT更改GS基礎）
AMD的設計是syscall不更改RSP以指向內核堆棧，并且不讀取/寫入任何內存，因此syscall它本身可以很快。但是隨后您進入內核，其中所有寄存器都保存著它們的用戶空間值。請參閱為什么Windows64使用與x86-64上所有其他操作系統不同的調用約定？在2000年左右內核開發人員和AMD架構師之間討論郵件列表討論的一些鏈接，在出售任何AMD64 CPU之前調整其設計syscall并swapgs使其可用。
顯然，要跟蹤GS當前是內核還是用戶值對于錯誤處理是很棘手的：沒有辦法說“我現在要kernelgs”。您必須知道是否swapgs在任何錯誤處理路徑中運行。唯一的指令是交換，而不是將其設置為一個與另一個。
閱讀arch/x86/entry/entry_64.S例如https://github.com/torvalds/linux/blob/9fb71c2f230df44bdd237e9a4457849a3909017d/arch/x86/entry/entry_64.S#L1267（來自當前Linux）中的注釋，其中提到了usergs，下一個注釋塊描述了swapgs在執行之前使用內核gsbase跳轉到一些錯誤處理代碼。
IIRC，Linux內核[gs:0]在該線程的內核堆棧的最低地址處擁有一個線程信息塊。該塊包括內核堆棧指針（作為絕對地址，而不是相對于gs）。
如果此錯誤基本上是在誘使內核rsp從用戶控制的gsbase加載內核，或者搞砸了死胡同，swapgs從而使它gs在某些時候出現錯誤，我不會感到驚訝。
- 1 回答
- 0 關注
- 361 瀏覽
添加回答
舉報
0/150
提交
取消