西奧·德·拉特 計畫加強W^X（Write XOR Execute）記憶體保護機制。 該機制的本質是進程記憶體頁面不能同時被存取以進行寫入和執行。 因此，只有在禁止寫入後才能執行程式碼，並且只有在禁止執行後才可以寫入記憶體頁。 W^X 機制有助於保護使用者空間應用程式免受常見緩衝區溢位攻擊（包括堆疊溢位），並且在 OpenBSD 中活躍 .
從 W^X 的工作開始，很明顯這是一條漫長的道路，因為有大量的應用程式使用 JIT。 JIT 實作可分為三類：
- 在W和X狀態之間切換內存，接受系統呼叫的“成本” .
- 在同一記憶體的一對 W 和 X 對映之間建立別名。
- 最「髒」的選項需要允許同時記錄和執行的 W|X 記憶體模型。
目前，使用第三個選項的程序明顯較少，而使用第一個和第二個選項的程序則較多。 然而，由於需要使用 W|X JIT（主要是 Chromium 和 Iridum）運行程序，因此添加了「wxallowed」檔案系統掛載選項，該選項允許記憶體同時用於寫入和執行，以防可執行 ELF檔案標有“wxneeded”標記，並且應用程式本身還使用機制進行了額外保護 и 分別限制所使用的系統呼叫清單和應用程式可用的檔案系統部分。
為了使此類應用程式中的漏洞利用進一步複雜化，建議對該機制進行補充 ，它檢查系統呼叫是否正在從可寫記憶體頁執行。 如果該頁可寫，則該進程將被強制終止。 這樣，攻擊者將無法利用系統調用，並且將被迫嘗試在 JIT 實現中找到必要的小工具，甚至直接在內部進行更困難的檢測系統調用存根的工作 .
Chrome/Iridium 程序已經使用 Promise 和 Reveal 得到了相當可靠的保護，但是刪除使用 write(2) 系統呼叫的能力顯然有一些優勢，因為它給攻擊者帶來了額外的困難。 但是，如果 JIT 實作使用 W|X 記憶體中的本機系統調用，也會出現困難。 然而，我們有理由希望情況不會如此，因為 ABI 已更改多次，但從未有人報告過問題。
這些變更已經在 OpenBSD-Current 分支的常規快照中提供，歡迎有興趣的每個人進行測試。
關於 Chrome/Iridium 中該模式出現的相關新聞值得 Theo 單獨評論 。 從他的角度來看，這對於某些使用模式來說是可以接受的，但可能不是全部，因為這種模式會顯著增加處理器的負載。 目前，如果您對 /usr/local 停用“wxallowed”，Chrome 基本上可以正常工作，儘管某些擴充功能可能會出現問題（ghostery 就是一個例子）。 不管怎樣，Theo 希望在不久的將來，JITless 模式下的成熟工作能夠進入全面運作的狀態。
來源： opennet.ru