<story><title>W^X now mandatory in OpenBSD</title><url>http://undeadly.org/cgi?action=article&amp;sid=20160527203200</url></story><parent_chain></parent_chain><comment><author>near</author><text>I&amp;#x27;ve always been in favor of all OpenBSD security enhancements I&amp;#x27;ve seen, but I have to say, and please hear me out, this is an objectively terrible idea.&lt;p&gt;Yes, most programs should disallow W|X by default. But trying to banish the entire practice with a mount flag, knowing full well few people will go that far to run a W|X application, is bad practice. I&amp;#x27;d rather see this as another specialty chmod flag ala SUID, SGID, etc. Or something along those lines. One shouldn&amp;#x27;t have to enable filesystem-wide W|X just to run one application.&lt;p&gt;The thing is, when you actually &lt;i&gt;do&lt;/i&gt; need W|X, there is no simple workaround. Many emulators and JITs &lt;i&gt;need&lt;/i&gt; to be able to dynamically recompile instructions to native machine code to achieve acceptable performance (emulating a 3GHz processor is just not going to happen with an interpreter.) For a particularly busy dynamic recompiler, having to constantly call mprotect to toggle the page flags between W!X and X!W will impact performance too greatly, since that is a syscall requiring a kernel-level transition.&lt;p&gt;We also have app stores banning the use of this technique as well. This is a very troubling trend lately; it is throwing the baby out with the bathwater.&lt;p&gt;EDIT: tj responded to me on Twitter: &amp;quot;the per-mountpoint idea is just an initial method; it&amp;#x27;ll be refined as time goes on. i think per-binary w^x is in the pipeline.&amp;quot; -- that will not only resolve my concerns, but in fact would be my ideal design to balance security and performance.</text></comment>
<story><title>W^X now mandatory in OpenBSD</title><url>http://undeadly.org/cgi?action=article&amp;sid=20160527203200</url></story><parent_chain></parent_chain><comment><author>sillysaurus3</author><text>This paper&amp;#x27;s thesis is that W^X does not work, and not because of any of the reasons presented in this thread: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;cseweb.ucsd.edu&amp;#x2F;~hovav&amp;#x2F;dist&amp;#x2F;geometry.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;cseweb.ucsd.edu&amp;#x2F;~hovav&amp;#x2F;dist&amp;#x2F;geometry.pdf&lt;/a&gt;&lt;p&gt;The paper says that to bypass W^X protection, you can simply scan an executable for &amp;quot;the instruction you want to use, followed by a RET&amp;quot;. The paper calls these &amp;quot;gadgets.&amp;quot;&lt;p&gt;You can write any function you want by using these gadgets: simply call them. When you call a gadget, it executes the corresponding instruction, then returns. This allows you to write arbitrary functions, since real-world programs are large enough that they have a massive number of gadgets for you to choose from.&lt;p&gt;Can someone provide a counterargument?</text></comment>