當通過 far 呼叫從兼容模式切換到相同特權級別的 64 位模式時，段暫存器中的 BASE 或 LIMIT 等欄位將被忽略，并且 64 位指標暫存器都可用。但是，如果忽略 BASE 欄位，堆疊基地址將隱式變為 0x0，這意味著將引發隱式堆疊開關，對嗎？而如果我的理解是正確的，那么通過ret指令回傳時，CPU是如何切換回原來的堆疊的呢？
uj5u.com熱心網友回復：
SDM 確實使用術語“隱式堆疊切換”來描述這種行為，但僅限于使用呼叫門執行呼叫時。
...當使用呼叫門對同一特權級別的段執行遠呼叫時，由于進入 64 位模式，會發生隱式堆疊切換。SS 選擇器不變，但堆疊段訪問使用 0x0 的段基址，忽略限制，默認堆疊大小為 64 位。RSP 的完整值用于偏移量，其中高 32 位未定義。
盡管 SDM 沒有描述在不使用呼叫門的情況下執行呼叫時的行為，但我觀察到的行為是相同的。回傳地址 (cs:rip) 被推送到新堆疊（忽略 ss.base），并且回傳 32 位代碼的 far ret 有效。當然，32 位代碼繼續照常使用 ss.base。
（在我的測驗中，RSP 的高位在進入兼容模式之前為 0，在執行回呼到 64 位模式時保持為 0。）
以下是運行執行以下操作的程式后的記憶體轉儲：
ss.base = 0x80
esp = 8385f118
push 32323232
push esp
far call to 64-bit code（回傳地址是 20:776bb1e2）
push 64646464
push rsp
far call to 32-bit代碼（回傳地址為 38:776bb208）
push 30303030
push esp
add esp, 8
far ret
add rsp, 10
far ret
push 31313131
push esp
8385f0f0: 00000000 00000000 8385f100 00000000
8385f100: 64646464 00000000 776bb1e2 00000020
8385f110: 00000000 00000000 00000000 00000000
8385f120: 00000000 00000000 00000000 00000000
8385f160: 00000000 00000000 8385f0ec 30303030
8385f170: 776bb208 00000038 00000000 00000000
8385f180: 00000000 00000000 8385f10c 31313131
8385f190: 8385f114 32323232 00000000 00000000
uj5u.com熱心網友回復：
從兼容模式切換到相同權限級別的 64 位模式時會發生隱式堆疊切換嗎？
從兼容模式切換到相同權限級別的 64 位模式時，不會發生隱式堆疊切換；除非它是通過使用 IST 機制的中斷來完成的。
但是，如果忽略 BASE 欄位，堆疊基地址將隱式變為 0x0，這意味著將引發隱式堆疊開關，對嗎？
對于 80x86；通常，線性地址是通過將段內的偏移量添加到段的基址來計算的，其中段的基址存盤在段暫存器的“隱藏”部分中。例如，在 32 位代碼中，如果你這樣做了，mov eax,[esp]那么 CPU 會計算“linear_address = SS.base ESP”。
因為大多數作業系統使用“平面記憶體模型”，其中段被有效禁用（通過將所有段基數設定為零并將所有段限制設定為“最大值”）；CPU 優化了這種特定情況，如果已知段基數為零，則跳過加法（例如，如果mov eax,[esp]CPU 已經知道 SS.base 為零，則該 CPU 可能會作弊并執行“linear_address = ESP”）。
對于 64 位代碼，不包括 FS 和 GS 段暫存器，無論是否存在，都假定段暫存器“隱藏”部分（用于段基址）中的值為零；并且 CPU 知道段基總是“假定為零”并且總是優化地址計算（通過不添加段基）。
在相同權限級別從兼容模式切換到 64 位模式時；有兩種可能性：
a) SS 的段基址在兼容模式下為零，在 64 位中變為“假定為零”，因此堆疊的地址不會改變（見注）。
b) SS 的段基址在兼容模式下非零，在 64 位中變為“假定為零”，因此堆疊地址確實發生了變化。
后一種可能性（兼容模式下的非零 SS 段基數）將是我強烈避免的；因為它對程式員來說非常混亂，并且具有“高于正常”的怪癖/勘誤風險（例如，未來的 CPU 會以稍微不同的順序執行操作并將回傳資訊存盤在“ss.base esp”而不是“0 特別是“）。
注意：在 64 位代碼中，任何只更新暫存器下半部分的內容都會導致 64 位暫存器的上半部分歸零（例如，將值 0x9ABCDEF0 加載到 ESP 將導致 RSP 設定為 0x000000009ABCDEF0）。我認為這不會在兼容模式下發生（或者至少，我認為這不能保證會發生）。當您切換回 64 位時，這可能會導致在切換到兼容模式之前留在 RSP 上半部分的“垃圾”仍然存在（例如，可能導致堆疊地址從 0x9ABCDEF0 更改為 0x123456789ABCDEF0）。
uj5u.com熱心網友回復：
請注意，在 x86 術語中，“堆疊切換”具有特定的技術含義，涉及從 TSS 加載新的 SS:[ER]SP，例如當用戶空間運行int指令時。這不是你在說的，只是ss.base esp可能與0 rsp.
是的，我認為這是正確的，在您的 32 位代碼具有 SS.base ！= 0 的不尋常情況下。
所有主流作業系統都使用平面記憶體模型，CS/DS/ES/SS 的基數都為零（并且 limit=-1），所以這不是問題。
順便說一句，Windows x64 實際上在其 DLL 中執行此用戶空間模式切換，作為其 WoW64 的一部分（即 Windows64 上的 Windows（32 位））。sysenter用戶空間不是直接呼叫內核，而是call使用sycall.
如果 32 位代碼以非零 SS 基數運行，那將不那么方便。（我不確定 CS:EIP 回傳地址是否ss.base ESP會被推[RSP]送到rspss.base rsp
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/424424.html