View source for W^X

{{Short description|Operating system memory security feature}}
{{Use American English|date = April 2019}}
{{Use mdy dates|date = April 2019}}
'''W^X''' ("write xor execute", pronounced ''W [[Exclusive or|xor]] X'') is a [[computer insecurity|security]] feature in [[operating system]]s and [[virtual machine]]s. It is a [[memory (computers)|memory]] protection policy whereby every [[paging|page]] in a [[process (computer science)|process]]'s or [[kernel (operating system)|kernel]]'s [[address space]] may be either writable or [[executable]], but not both. Without such protection, a program can write (as data "W") CPU instructions in an area of memory intended for data and then run (as executable "X"; or read-execute "RX") those instructions. This can be dangerous if the writer of the memory is malicious. W^X is the Unix-like terminology for a strict use of the general concept of [[executable space protection]], controlled via the {{code|mprotect}} system call.
W^X is relatively simple on [[Processor design|processor architectures]] that support fine-grained page permissions, such as [[Sun Microsystems|Sun]]'s [[SPARC]] and SPARC64, [[AMD]]'s [[x86-64]], [[Hewlett-Packard]]'s [[PA-RISC]], HP's (originally [[Digital Equipment Corporation]]'s) [[DEC Alpha|Alpha]], and [[ARM architecture|ARM]].
The term W^X has also been applied to file system write/execute permissions to mitigate file write vulnerabilities (as with in memory) and attacker persistence.<ref>{{cite web |url=https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149|title=Enforce execve() restrictions for API > 28}}</ref> Enforcing restrictions on file permissions can also close gaps in W^X enforcement caused by memory mapped files.<ref>{{cite web |url=https://www.linux-magazine.com/Issues/2017/204/Kernel-News|title=Zack's Kernel News
}}</ref><ref>{{cite web |url=https://lore.kernel.org/patchwork/cover/798675/#1002174|title=S.A.R.A. a new stacked LSM
}}</ref> Outright forbidding the usage of arbitrary native code can also mitigate kernel and CPU vulnerabilities not exposed via the existing code on the computer.<ref>{{cite web |url=http://phrack.org/issues/52/6.html|title=Hardening the Linux Kernel (series 2.0.x)}}</ref> A less intrusive approach is to lock a file for the duration of any mapping into executable memory, which suffices to prevent post-inspection bypasses.
== Compatibility ==
Some early [[Intel 64]] processors lacked the [[NX bit]] required for W^X, but this appeared in later chips. On more limited processors such as the [[Intel]] [[i386]], W^X requires using the CS [[code segment]] limit as a "[[line in the sand]]", a point in the address space above which execution is not permitted and data is located, and below which it is allowed and executable pages are placed. This scheme was used in [[Exec Shield]].<ref>{{cite web|title=i386 W^X|url=http://marc.info/?l=openbsd-misc&m=105056000801065| date= 2003-04-17 |access-date=19 June 2014}}</ref>
[[Linker (computing)|Linker]] changes are generally required to separate data from code (such as [[trampoline (computers)|trampoline]]s that are needed for linker and [[library (computer science)|library]] [[run-time system|runtime]] functions). The switch allowing mixing is usually called <code>execstack</code> on Unix-like systems<ref>{{man|8|execstack|ManKier}}.</ref>
W^X can also pose a minor problem for [[just-in-time compilation]], which involves an interpreter generating machine code on the fly and then running it. The simple solution used by most, historically including [[Firefox]], involves just making the page executable after the interpreter is done writing machine code, using {{code|VirtualProtect}} on Windows or {{code|mprotect}} on Unix-like operating systems. The other solution involves mapping the same region of memory to two pages, one with RW and the other with RX.<ref name=firefox/> There is no simple consensus on which solution is safer: supporters of the latter approach believe allowing a page that has ever been writable to be executed defeats the point of W^X (there exists an [[SELinux]] policy to control such operations called {{code|allow_execmod}}) and that [[address space layout randomization]] would make it safe to put both pages in the same process. Supporters of the former approach believe that the latter approach is only safe when the two pages are given to two separate processes, and [[inter-process communication]] would be costlier than calling {{code|mprotect}}.
== History ==
W^X was first implemented in [[OpenBSD]] 3.3, released May 2003. In 2004, Microsoft introduced a similar feature called DEP ([[Data Execution Prevention]]) in [[Microsoft Windows|Windows]] XP. Similar features are available for other operating systems, including the [[PaX]] and [[Exec Shield]] patches for [[Linux]], and [[NetBSD]]'s implementation of PaX. In [[Red Hat Enterprise Linux]] (and automatically [[CentOS]]) version 5, or by Linux Kernel 2.6.18-8, [[SELinux]] received the {{code|allow_execmem}}, {{code|allow_execheap}}, and {{code|allow_execmod}} policies that provide W^X when disabled.
Although W^X (or DEP) has only protected userland programs for most of its existence, in 2012 Microsoft extended it to the Windows kernel on the x86 and ARM architectures.<ref>{{cite web|title=Exploit mitigation improvements in Win8|url=https://www.blackhat.com/html/bh-us-12/bh-us-12-briefings.html#Miller2}}</ref> In late 2014 and early 2015, W^X was added in the OpenBSD kernel on the AMD64 architecture.<ref>{{cite web|title=W^X protection for the AMD64 kernel| url= https://marc.info/?l=openbsd-tech&m=142120787308107&w=2}}</ref> In early 2016, W^X was fully implemented on NetBSD's AMD64 kernel and partially on the i386 kernel.
[[macOS]] computers running on [[Apple silicon]] processors enforce W^X for all programs. Intel-based Macs enforce the policy only for programs that use the OS's Hardened Runtime mode.<ref>{{Cite web |title=Porting Just-In-Time Compilers to Apple Silicon |url=https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon |access-date=2022-04-17 |website=developer.apple.com}}</ref><ref>{{Cite web |date=2020-07-17 |title=ARM Macs FAQ |url=https://www.securemac.com/news/arm-macs-faq |access-date=2022-04-17 |publisher=SecureMac |language=en}}</ref>
Starting with [[Firefox]] 46 in 2016 and ending with [[Firefox]] 116 in 2023, Firefox's virtual machine for [[JavaScript]] implemented the W^X policy.<ref name=firefox>{{cite web|title=W^X JIT-code enabled in Firefox| url = http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox |access-date=2016-04-29}}</ref> This was later rolled back on some platforms for performance reasons, though remained in others which enforce W^X for all programs.<ref>{{cite web |title=1835876 - Consider disabling code memory protection in the content process |url=https://bugzilla.mozilla.org/show_bug.cgi?id=1835876 |website=bugzilla.mozilla.org |publisher=Mozilla |access-date=1 July 2024 |language=en-us}}</ref>
Starting with .NET 6.0 in 2021, .NET now uses W^X.<ref>{{cite web |title=What's new in .NET 6 |url=https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-6#security |website=docs.microsoft.com |publisher=Microsoft |access-date=9 November 2021 |language=en-us}}</ref>
== References ==
{{Reflist}}
== External links ==
*[http://www.openbsd.org/33.html OpenBSD-3.3 announcement, public release of W^X]
*[http://www.openbsd.org/papers/ven05-deraadt/index.html Slides from a presentation by OpenBSD lead developer Theo de Raadt covering W^X]
{{DEFAULTSORT:WX}}
[[Category:Operating system security]]