W^X is a security feature in operating systems and virtual machines. It is a memoryprotection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. Without such protection, a program can write CPU instructions in an area of memory intended for data and then run 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 system call. W^X is relatively simple on processors that support fine-grained page permissions, such as Sun's SPARC and SPARC64, AMD's AMD64, Hewlett-Packard's PA-RISC, HP's Alpha, and ARM. W^X has also been applied to file system write/execute permissions to mitigate file write vulnerabilities and attacker persistence. Enforcing restrictions on file permissions can also close gaps in W^X enforcement caused by memory mapped files. Outright forbidding the usage of arbitrary native code can also mitigate kernel and CPU vulnerabilities not exposed via the existing code on the computer.
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 Inteli386, 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. Linker changes are generally required to separate data from code. The switch allowing mixing is usually called execstack on Unix-like systems W^X can also pose a minor problem for just-in-time compilation, which involves an interpreter generating machine codeon the fly and then running them. The simple solution used by most, including Firefox, involves just making the page executable after the interpreter is done writing machine code, using on Windows or on Unix-likes. The other solution involves mapping the same region of memory to two pages, one with RW and the other with RX. There is no simple consensus on which solution is safer: supporters of the latter approach believe that some critics believe allowing a page that has ever been writable to be executed defeats the point of W^X 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.
History
W^X was first implemented in OpenBSD 3.3, released May 2003. In 2004, Microsoft introduced a similar feature called DEP in 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 version 5, or by Linux Kernel 2.6.18-8, SELinux received the,, and policies that provide W^X when disabled. Although W^X 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. In late 2014 and early 2015, W^X was added in the OpenBSD kernel on the AMD64 architecture. In early 2016, W^X was fully implemented on NetBSD's AMD64 kernel and partially on the i386 kernel. Starting with Firefox 46 in 2016, Firefox's virtual machine for JavaScript also implements the W^X policy.
