西奥·德·拉特 计划加强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