雖然自從 Tiger Lake CPU 作為英特爾控制流執行技術 (CET) 的一部分以來，Intel Shadow Stack 支持就一直存在，但最終對於 Linux 6.4 內核來說，這個安全功能是通過主線 Linux 內核啟用的。
作為 CET 的一部分，英特爾 Linux 工程師長期以來一直致力於影子堆棧支持。 CET 的另一部分，間接分支跟踪，在 Linux 5.18 中被上游。
英特爾針對 Linux 6.4 的影子堆棧功能是返回地址保護，以抵禦面向返回的編程 (ROP) 攻擊。最新的 AMD CPU 還提供與 Intel 實施兼容的 Shadow Stack 功能。
長期擔任英特爾 Linux 工程師的 Dave Hansen 提交了x86/shstk 拉取請求 週一終於介紹了這個功能。他在那條消息中解釋道:
請為 6.4 拉取 x86/shstk。這是期待已久的 Shadow Stack 支持。這是長期以來最受期待的硬件安全功能。 AMD 和 Intel 都有（兼容的）實現。自第 11 代 CPU 以來，它一直出現在英特爾方面，但它在途中遇到了一些絆腳石，而且有點遲緩。
整個事情中最棘手的部分（恕我直言）是影子堆棧存在於權限灰色區域。影子堆棧 PTE 的字面意思是 Write=0，但有些指令_can_ 寫入它。 PTE 也不能是只讀的，因此不能進行 COW。他們是古怪的人。
Write=0,Dirty=1 PTE權限也意味著dirty bit不能像以前那樣隨意使用了。這兩件事結合起來造成了相當數量的 PTE 管理流失。
還有幾件事你應該知道:
1。有大量的核心客戶流失。它有來自 mm folks 的確認，我希望 Andrew 不會感到驚訝。這些向 pte_mkwrite() 添加了一個 VMA 參數。 Andrew 的堆中有一個新用戶需要在與 mm 樹合併之前得到修復。
2。影子堆棧的用戶空間兼容性問題異常猖獗。雖然轉移到新的 arch_prctl() 值有所幫助，但我們仍然可以設想這些舊代碼可能會影響我們的場景。如果在實踐中出現任何問題，該計劃將嘗試禁止任何有問題的應用程序使用影子堆棧。我們顯然應該留意這些。
3。這與 x86/mm 中的 LAM 代碼衝突。我將在發送 x86/mm 時討論分辨率。
在撰寫本文時，Linus Torvalds 尚未引入 Shadow Stack 支持或發表任何郵件列表評論。我們將看看 Linus 為 Linux 6.4 引入此功能是否一切順利，或者他是否對上述評論有所保留。希望這個有助於抵禦 ROP 攻擊的 Intel/AMD 安全功能最終會被合併。
