Editing W^X (section)

{{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 security policy in [[Operating system|operating systems]] and [[Software framework|software frameworks]]. It implements [[executable space protection]] by ensuring every [[memory page]] (a fixed-size block in a program’s [[virtual address space]], the memory layout it uses) is 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. 

The terminology was first introduced in 2003 for [[Unix-like]] systems, but is today also used by some multi-platform systems (such as [[.NET]]<ref name=":0" />). Other operating systems have adopted similar policies under different names (e.g., [[Data execution prevention|DEP]] in Windows).

In Unix, W^X is typically controlled via the [[mprotect]] system call. It is relatively simple on [[Processor design|processor architectures]] supporting fine-grained page permissions, such as [[SPARC]], [[x86-64]], [[PA-RISC]], [[Alpha (microprocessor)|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.