The NX bit, which stands for Never eXecute, is a technology used in CPUs to segregate areas of memory for use by either storage of processor instructions (or code) or for storage of data, a feature normally only found in Harvard architecture processors. However, the NX bit is being increasingly used in conventional von Neumann architecture processors, for security reasons.
An operating system with support for the NX bit may mark certain areas of memory as non-executable. The processor will then refuse to execute any code residing in these areas of memory. The general technique, known as executable space protection, is used to prevent certain types of malicious software from taking over computers by inserting their code into another program's data storage area and running their own code from within this section; this is known as a buffer overflow attack.
Intel markets the feature as the XD bit, for eXecute Disable. AMD uses the name Enhanced Virus Protection. The ARM architecture refers to the feature as XN for eXecute Never; it was introduced in ARM v6.
x86 processors, since the 80286, included a similar capability implemented at the segment level. However, current operating systems implementing the flat memory model cannot use this capability. There was no 'Executable' flag in the page table entry (page descriptor) in the 80386 and later x86 processors, until, to make this capability available to operating systems using the flat memory model, AMD added a "not executable" or NX bit to the page table entry in its AMD64 architecture, providing a mechanism that can control execution per page rather than per whole segment.
The page-level mechanism has been around for years in various other processor architectures such as DEC's (now HP's) Alpha, Sun's SPARC, and IBM's System/370-XA, System/390, z/Architecture and PowerPC. Intel implemented a similar feature in its Itanium (Merced) processor—having IA-64 architecture—in 2001, but did not bring it to the more popular x86 processor families (Pentium, Celeron, Xeon, etc.) In the x86 architecture it was implemented by AMD, as NX bit, for use by its AMD64 line of processors, such as the Athlon 64 and Opteron. The term NX bit seems to have now become commonly used to generically describe similar technologies in other processors.
After AMD's decision to include this functionality in its AMD64 instruction set, Intel implemented a similar feature in x86 processors beginning with the Pentium 4 processors based on later iterations of the Prescott core.
The NX bit specifically refers to bit number 63 (i.e. the most significant bit) of a 64-bit entry in the page table. If this bit is set to 0, then code can be executed from that page; if set to 1, code cannot be executed from that page, and anything residing there is assumed to be data. Also note that it is used only with Physical Address Extension (PAE) page table format, because the x86's original 32-bit page table format has no bit 63 and therefore no bit to disable/enable execution.
Software emulation of feature
Prior to the onset of this feature within the hardware, various operating systems attempted to emulate this feature through software.
An operating system with the ability to emulate and/or take advantage of an NX bit may prevent the stack and heap memory areas from being executable, and may prevent executable memory from being writable. This helps to prevent certain buffer overflow exploits from succeeding, particularly those that inject and execute code, such as the Sasser and Blaster worms. These attacks rely on some part of memory, usually the stack, to be both writable and executable; if it is not, the attack fails.
Microsoft Windows uses NX protection on critical Windows services exclusively by default. Under Windows XP or Server 2003, the feature is called Data Execution Prevention (abbreviated DEP), and it can be configured through the advanced tab of "System" properties. If the x86 processor supports this feature in hardware, then the NX features are turned on automatically in Windows XP/Server 2003 by default. If the feature is not supported by the x86 processor, then no protection is given.
"Software DEP" is unrelated to the NX bit, and is what Microsoft calls their enforcement of Safe Structured Exception Handling. Software DEP/SafeSEH checks when an exception is thrown to make sure that the exception is registered in a function table for the application, and requires the program to be built with it.
Early implementations of DEP provided no address space layout randomization (ASLR), which allowed potential return-to-libc attacks that could have been feasibly used to disable DEP during an attack. The PaX documentation elaborates on why ASLR is necessary; a proof-of-concept was produced detailing a method by which DEP could be circumvented in the absence of ASLR. It may be possible to develop a successful attack if the address of prepared data such as corrupted images or MP3s can be known by the attacker. Microsoft added ASLR functionality in Windows Vista and Windows Server 2008 to address this avenue of attack.
- Hardware Supported Processors: x86-64 (AMD64 and Intel 64), IA-64, Efficeon, Pentium M (later revisions), AMD Sempron (later revisions)
- Emulation: No
- Other Supported: None
- Standard Distribution: Windows XP Service Pack 2, Windows Server 2003 Service Pack 1, Windows XP Professional x64 Edition, Windows Vista
- Release Date: August 6, 2004
Functional comparison of technologies
Here, features of the NX technologies will be compared and contrasted.
Generally, NX bit emulation is available only on x86 CPUs. The sections within dealing with emulation are concerned only with x86 CPUs unless otherwise stated.
While it has been proven that some NX bit emulation methods incur an extremely low overhead, it has also been proven that such methods can become inaccurate. On the other hand, other methods may incur an extremely high overhead and be absolutely accurate. No method has been discovered as of yet without a significant trade-off, whether in processing power, accuracy, or virtual memory space.
Overhead is the amount of extra CPU processing power that is required for each technology to function. It is important because technologies which somehow emulate or supply an NX bit will usually impose a measurable overhead; while using a hardware supplied NX bit will impose no measurable overhead. All technologies create overhead due to the extra programming logic that must be created to control the state of the NX bit for various areas of memory; however, evaluation is usually handled by the CPU itself when a hardware NX bit exists, and thus produces no overhead.
Some technologies approximately emulate (or approximate) an NX bit on CPUs which do not support them. Others strictly emulate an NX bit for these CPUs, but decrease performance or virtual memory space significantly.
Control over restrictions
Some technologies allow executable programs to be marked so that the operating system knows to relax the restrictions imposed by the NX technology for that particular program. Various systems provide various controls; such controls are described here.
In the API, runtime access to the NX bit is exposed through the Win32 API calls VirtualAlloc[Ex] and VirtualProtect[Ex]. In these functions, a page protection setting is specified by the programmer. Each page may be individually flagged as executable or non-executable. Despite the lack of previous x86 hardware support, both executable and non-executable page settings have been provided since the beginning. On pre-NX CPUs, the presence of the 'executable' attribute has no effect. It was documented as if it did function, and, as a result, most programmers used it properly.
In the PE file format, each section can specify its executability. The execution flag has existed since the beginning of the format; standard linkers have always used this flag correctly, even long before the NX bit.
Because of these things, Windows is able to enforce the NX bit on old programs. Assuming the programmer complied with "best practices", applications should work correctly now that NX is actually enforced. Only in a few cases have there been problems; Microsoft's own .NET Runtime had problems with the NX bit and was updated.
In Microsoft's Xbox, although the CPU does not have the NX bit, newer versions of the XDK set the code segment limit to the beginning of the kernel's .data section (no code should be after this point in normal circumstances). This was probably in response to the 007: Agent Under Fire saved game exploit; however, this change does not fix the problem, as the memory from which the payload executes is well below the beginning of the kernel's .data section.
Starting with version 51xx, this change was also implemented into the kernel of new Xboxes. This broke the techniques old exploits used to become a TSR; new versions were quickly released supporting this new version because the fundamental exploit was unaffected.
- AMD, Intel put antivirus tech into chips
- Microsoft Interviewed on Trustworthy Computing and NX
- Changes to Functionality in Microsoft Windows XP Service Pack 2 Part 3: Memory Protection Technologies
- Microsoft Security Developer Center: Windows XP SP 2: Execution Protection