對於許多剛接觸底層開發或資訊安全的工程師來說，Spectre 類型的漏洞可能聽起來非常抽象。簡單來說，這類漏洞利用了現代 CPU 的「推測執行」（Speculative Execution）特性——CPU 為了加速運算，會預測接下來要執行的路徑並提前執行。如果預測錯誤，CPU 會捨棄結果，但執行過程中留下的快取（Cache）狀態卻會被攻擊者透過側信道（Side-channel）分析讀取，進而洩漏機密資料。
為了對抗 Spectre v2（針對分支目標緩衝區的攻擊），Intel 與 AMD 分別開發了多種防禦機制。然而，MIT CSAIL 的研究員 Daniël Trujillo 與 Mengjia Yan 最近提出了一種名為 Interrupt Injection（中斷注入） 的攻擊技術，證明即使開啟了所有預設防禦，攻擊者仍能繞過這些保護。
核心問題：從 TOCTOU 到 TONTOU
在軟體安全中，我們常聽到 TOCTOU（Time-of-Check to Time-of-Use，檢查時間與使用時間之差），這是一種競爭條件（Race Condition）漏洞。研究人員將這次的硬體攻擊定義為 TONTOU，即 Time-of-Neutralization to Time-of-Use（中和時間與使用時間之差）。
為什麼會有這個漏洞？ 目前的 Spectre v2 防禦邏輯通常是： 中和（Neutralization）： 在進入核心（Kernel entry）或返回使用者空間（Kernel return）之前，清理或隔離分支預測器（Branch Predictor）的狀態，防止攻擊者先前「訓練」的惡意路徑影響核心執行。 使用（Use）： 核心執行實際的指令。
防禦機制假設在這兩個步驟之間，沒有任何惡意代碼可以運行。但研究人員發現，硬體中斷（Hardware Interrupts） 打破了這個假設。由於 Linux 允許使用者程式以奈秒（nanosecond）級別的精度調度中斷，攻擊者可以精準地將中斷「注入」到中和與使用之間的極短時間窗中。
技術實作細節
攻擊流程 當 CPU 執行防禦序列（例如 AMD 的 Safe-RET）時，如果此時觸發了一個中斷，CPU 會暫停當前流程去處理中斷。如果這個中斷恰好發生在「預測器已清理」但「指令尚未執行」的間隙，中斷處理程序（Interrupt Handler）本身就可以變成一個「訓練工具」（Training Gadget）。
攻擊者利用先前發現的 Inception (CVE-2023-20569) 漏洞，在處理中斷時填充返回棧緩衝區（Return Stack Buffer, RSB），將預測目標導向攻擊者指定的地址。當中斷處理完成並返回時，CPU 會帶著被「重新污染」的預測狀態繼續執行，從而觸發推測執行洩漏。
提高成功率的手段 在 AMD Zen 2 平台上，這個時間窗極其狹窄，僅有 2 個指令（約 6 個位元組）。為了增加命中率，研究人員採取了以下手段： 快取剔除（Cache Eviction）： 利用同一個核心的另一個超執行緒（Sibling Hyperthread）將該時間窗內的指令從 L1 和 L2 快取中剔除，強迫 CPU 從較慢的記憶體讀取，從而拉長時間窗。 特定系統呼叫： 選擇 write syscall，使其能控制兩個暫存器，增加可控性。
透過這些手段，中斷成功落在時間窗內的機率提升至 5% 到 12%。
實測影響與結果
研究人員在多款 CPU 上進行了測試，結果顯示該技術具有普遍性：
處理器平台 誤預測成功率 (Misprediction Rate) 實際影響 :--- :--- :--- AMD Zen 2 0.75% 證實可洩漏核心記憶體 (5.47 bytes/sec)，能讀取 /etc/shadow Intel Arrow Lake 0.22% 觀察到誤預測，但未演示端到端洩漏 Intel Cascade Lake Refresh 0.037% 觀察到誤預測，但未演示端到端洩漏 AMD Zen 4 0% (此測試中) AMD 官方公告稱 Zen 1 至 Zen 4 均受影響
關鍵結論： 雖然在 Intel 平台上尚未演示完整的資料洩漏，但研究人員指出，誤預測是攻擊的必要條件。既然核心中已經存在已知的洩漏工具（Disclosure Gadgets），理論上 Intel 平台同樣面臨風險。
業界回應與修復方案
AMD 的做法 AMD 已承認此漏洞（公告編號 AMD-SB-7061），並指出問題與 Linux 實作 Safe-RET 防禦的方式有關。 修復機制： Linux 核心已提交修補程式（commit 標題為 "x86/bugs: Make Safe-RET robust against interrupt injection"）。該修補程式會修正暫存器狀態，使其如同 Safe-RET 序列已完成，並避免在中斷返回後執行 RET 指令，從而封堵攻擊路徑。
Intel 的做法 Intel 支付了 bug bounty 獎金，但不認為需要採取額外修復措施。Intel 主張該攻擊的可行性取決於多種因素，且現有的指導方針（INTEL-SA-00598）已涵蓋相關風險（儘管研究人員檢查後發現該文件並未提及中斷注入）。
工程判斷與建議
對於系統管理員與開發者而言，這次事件揭示了硬體防禦的一個核心弱點：原子性（Atomicity）的缺失。當防禦流程被非同步事件（如中斷）打斷時，原本安全的狀態會被重置。
實務建議： 更新核心： 針對使用 AMD 處理器的 Linux 伺服器，請務必確認核心已更新至包含 Safe-RET 強化修補程式的版本。 風險評估： 此攻擊需要「本地代碼執行」（Local Code Execution）權限。因此，風險最高的是多租戶共享系統（如共用主機、某些雲端容器環境），因為惡意使用者可以在同一台機器上運行代碼並嘗試注入中斷。 監控指標： 目前 /sys/devices/system/cpu/vulnerabilities/spec_rstack_overflow 雖能報告 SRSO 狀態，但尚未明確標示中斷注入的修復情況。建議透過檢查核心 commit 紀錄來確認。
總結 Interrupt Injection 提醒我們，即便有了硬體層級的緩解措施，軟體實作（如 Kernel）與硬體行為之間的交互作用仍可能產生新的漏洞。對於追求極高安全性的環境，應持續關注分支預測器相關的微碼更新與核心補丁。