NX Bit Hardware Background Software Emulation Of Feature

Although this sort of mechanism has been around for years in various other processor architectures such as Sun's Sparc, HP's Alpha, IBM's PowerPC, and even Intel's IA-64 architecture, the term is actually a name created by AMD for use by its AMD64 line of processors, such as the Athlon 64 and Opteron. It seems to have now become a common term used to generically describe similar technologies in other processors.

The NX bit specifically refers to bit number 63 (i.e. the very last bit, if the first bit starts at number 0, in a 64-bit integer) in the paging table entry of an x86 processor. If this bit is set to 0, then code can be executed from that page, otherwise if it's set to 1, code cannot be executed from that page, anything residing there is assumed to be only data. Also note, that these pages have to conform to the PAE page table format, rather than the original page table format for x86. The feature was first implemented in AMD64 processors, because the AMD64 architecture is a direct extension of the x86 architecture, but the feature doesn't require the processor to run in 64-bit mode, it will work in 32-bit mode as well. Because it works in 32-bit mode, other x86 manufacturers, such as VIAThere are two companies that go by the name VIA VIA Technologies, a Taiwanese manufacturer of integrated circuits VIA Rail, a Canadian passenger rail company VIA is also like a stop: VIA stop, when somebody says "You will board a train from Boston to San, TransmetaTransmeta is a US-based corporation that makes energy efficient x86 microprocessors. To date, it has produced two x86 compatible CPU architectures: the Crusoe and Efficeon processors. These CPUs have appeared in ultra-portable Laptops, Blade servers, Tabl, and of course IntelThe following article is about the multinational corporation; intel is also an abbreviation for intelligence, used in reference to military intelligence and espionage. Intel Corporation is a US-based multinational corporation that is best known for design are also back-porting this feature into the latest of their own x86 implementations.

However, Intel has decided to market the feature as the XD bit, for Execute Disable. However, it is implemented in exactly the same way as AMD's NX bit, so it's really the exact same thing.

2 Software emulation of feature

Prior to the onset of this feature within the hardware, various operating systems attempted to emulate this feature through software. They are described later in this page. Such as W^X or Exec Shield.

An operating systemIn computing, an operating system OS is the system software responsible for the direct control and management of hardware and basic system operations, as well as running application software such as word processing programs and web browsers. In general, t with the ability to emulate and/or take advantage of an NX bit may prevent the stackA stack is a data structure that works on the principle of Last In First Out (LIFO). This means that the last item put on the stack is the first item that can be taken off, like a physical stack of plates. A stack-based computer system is one that is base and heapDynamic memory allocation is the allocation of memory storage for use in a computer program during the runtime of that program. Memory is typically allocated from a large pool of all available unused memory called the heap but may also be allocated from m memory areas from being executable, and may prevent executable memory from being writable. This helps to prevent certain buffer overflow exploitAn exploit is a common term in the computer security community to refer to a piece of software that takes advantage of a bug, glitch or vulnerability, leading to privilege escalation or denial of service on a computer system. There are several methods ofs from succeeding, particularly those that inject and execute code, such as the SasserThe Sasser worm is a computer worm that spreads on computers running the Microsoft operating systems Windows XP and Windows 2000. Unlike other recent worms, the Sasser worm does not "travel by email", but connects directly to open ports on a computer. 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.

3 OS Implementations

Many operating systems implement or have available an NX policy, and some implement or have available NX emulation. Here is a list of such systems in alphabetical order, each with technologies ordered from newest to oldest.

At the head of each technology, there is a data table which gives the major features each technology supports. The nature of these technologies warrants the expedient diffusion of information about them, and so these tables are supplied to give a summary of the text below. The table is structured as below.

Hardware Supported Processors: (Comma separated list of CPU architectures)
Emulation: (No) or (Architecture Independent) or (Comma separated list of CPU architectures)
Other Supported: (None) or (Comma separated list of CPU architectures)
Standard Distribution: (No) or (Yes) or (Comma separated list of distributions or versions which support the technology)
Release Date: (Date of first release)

A technology supplying Architecture Independent emulation will be functional on all processors which aren't hardware supported. The "Other Supported" line is for processors which allow some grey-area method, where an explicit NX bit doesn't exist yet hardware allows one to be emulated in some way.

3.1 OpenBSD

3.1.1 W^X

Hardware Supported Processors: Alpha, AMD64, HPPA, Sparc
Emulation: IA-32 (x86)
Other Supported: None
Standard Distribution: Yes
Release Date: May 1, 2003

A technology in the OpenBSD operating system, known as W^X, currently takes leverage of NX technology in the AMD64 port, to have W^X fully available in hardware for these systems. W^X also (in current OpenBSD) supports W^X on CPUs without an NX bit.

W^X supports the NX bit on Alpha, AMD64, HPPA, and Sparc processors (but notably, not the Intel EM64T processor, which does not have the NX feature).

OpenBSD 3.3 shipped May 1, 2003, and was the first to include W^X.

3.2 Linux

Linux itself supports standard hardware NX, now in 32 bit mode on 64-bit CPUs via Ingo Molnar's NX enabler patch as well as in 64 bit mode on CPUs that support it (these include current 64-bit CPUs of AMD and future CPUs announced by Intel, Transmeta and VIA). Linus Torvalds has taken an interest in the NX patch, and believes it may be wise to have NX enabled by default; thus, it has been merged in 2.6.8. This is significant on 32-bit x86 kernels, which may run on both 32-bit x86 CPUs and 64-bit x86 compatible CPUs. A 32-bit x86 kernel would not normally expect the NX bit that an AMD64 or IA-64 supplies; the NX enabler patch assures that these kernels will attempt to use the NX bit if present.

As of this patch, Linux fully utilizes the hardware NX bit in supporting CPUs from Intel, AMD, Transmeta and VIA. The NX patch was released to the Linux kernel mailing list in June, 2004.

Non-execute functionality has also been present for other non-x86 processors supporting this functionality for many releases.

3.2.1 Exec Shield

Hardware Supported Processors: All that Linux supports NX on
Emulation: NX approximation using the code segment limit on IA-32 ( x86) and compatible
Other Supported: None
Standard Distribution: Red Hat
Release Date: May 2, 2003

Redhat kernel developer Ingo Molnar released a Linux kernel patch named Exec shield to approximate and utilize NX functionality on 32-bit x86 CPUs. Later, he released the Linux NX patch that supports hardware NX on 32-bit kernels.

The Exec Shield patch was released to the Linux Kernel Mailing List May 2, 2003. It was rejected for merging with the base kernel because it involved some intrusive changes to core code in order to handle the complex parts of the emulation trick.

3.2.2 PaX

Hardware Supported Processors: AMD64, IA-64, Alpha, PA-RISC, MIPS (32 and 64 bit)
Emulation: IA-32 ( x86)
Other Supported: PowerPC (32 and 64 bit), Sparc (32 and 64 bit)
Standard Distribution: Adamantix, Hardened Gentoo
Release Date: October 1, 2000

The PaX NX technology can emulate an NX bit or NX functionality, or use a hardware NX bit. PaX works on x86 CPUs that do not have the NX bit, such as 32-bit x86.

The PaX project originated October 1, 2000. It was later ported to 2.6, and is at the time of this writing still in active development.

The Linux kernel still does not ship with PaX (as of May, 2004); the patch must be merged manually.

3.3 Windows

Hardware Supported Processors: AMD64, IA-64, Efficeon, EM64T
Emulation: No
Other Supported: None
Standard Distribution: Windows XP Service pack 2, Windows Server 2003 Service pack 1
Release Date: August 6, 2004

Starting with Windows XP Service pack 2 and Windows Server 2003 Service Pack 1, the NX features were implemented for the first time on the x86 architecture. The service pack can be installed onto existing Windows XP or Windows Server 2003 installations, and future versions of Windows will ship with it preinstalled, but there are no current plans to backport it to previous versions of Windows, such as Windows 2000. Most notably, Windows uses NX protection on critical Windows services exclusively by default. Under Windows XP or Server 2003, the feature is called DEP (Data Execution Prevention), and it can be configured through the advanced properties of the "My Computer" icon. 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 a very rudimentary software-based version of DEP is enabled, but DEP is not as effective as it is when the processor supports NX and DEP together. DEP integrates the features of NX into its own featureset.

Outside of the x86 sphere, a version of NX also exists for Intel's IA-64 which is implemented into the Windows that operates that architecture.

4 Functional comparison of technologies

Here, features of the NX technologies will be compared and contrasted.

Generally, NX bit emulation is only available on x86 CPUs. The sections within dealing with emulation are only concerned 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.

4.1 Overhead

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 will 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 usually handled by the CPU itself when a hardware NX bit exists, and thus produces no overhead.

On CPUs supplying a hardware NX bit, none of the listed technologies imposes any significant measurable overhead unless explicitly noted.

4.1.1 Exec Shield

Exec Shield's legacy CPU support approximates (Ingo Molnar's word for it) NX emulation by tracking the upper code segment limit. This imposes only a few cycles of overhead during context switches, which is for all intents and purposes immeasurable.

4.1.2 PaX

PaX supplies two methods of NX bit emulation, called SEGMEXEC and PAGEEXEC. These are listed in the wikipedia article for PaX.

The SEGMEXEC method imposes a measurable, but low overhead, typically less than 1%. This is a constant scalar incurred due to the virtual memory mirroring used. SEGMEXEC also has the effect of halving the task's virtual address space, allowing the task to access less memory than it normally could. This is not a problem until the task requires access to more than half the normal address space, which is rare. SEGMEXEC does not cause programs to use more system memory (i.e. RAM); it only restricts how much they can access. On 32-bit CPUs, this becomes 1.5 GiB rather than 3GiB.

PaX supplies a method similar to Exec Shield's approximation in the PAGEEXEC as a speedup; however, when higher memory is marked executable, this method loses its protections. In these cases, PaX falls back to the older, variable overhead method used by PAGEEXEC to protect pages below the CS limit, which may become a quite high overhead operation in certain memory access patterns.

When the PAGEEXEC method is used on a CPU supplying a hardware NX bit, the hardware NX bit is used; no emulation is used, thus no significant overhead is incurred.

4.2 Accuracy

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. Here, these methods will be compared for accuracy.

All technologies listed here are 100% accurate in the presence of a hardware NX bit, unless otherwise stated.

4.2.1 Exec Shield

For legacy CPUs without an NX bit, Exec Shield fails to protect pages below the code segment limit; an mprotect() call to mark higher memory, such as the stack, executable will mark all memory below that limit executable as well. Thus, in these situations, Exec Shield's schemes fails. This is the cost of Exec Shield's low overhead (see above).

4.2.2 PaX

SEGMEXEC does not rely on such volatile systems as that used in Exec Shield, and thus does not encounter conditions in which finegrained NX bit emulation cannot be enforced; it does, however, have the halving of virtual address space mentioned above.

PAGEEXEC will fall back to the original PAGEEXEC method used before the speed-up when data pages exist below the upper code segment limit. In both cases, PaX' emulation remains 100% accurate; no pages will become executable unless the operating system explicitly makes them as such.

It is also interesting to note that PaX supplies mprotect() restrictions to prevent programs from marking memory in ways which produce memory useful for a potential exploit. This policy causes certain applications to cease to function; but can be disabled for affected programs.

4.3 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.

4.3.1 Exec Shield

Exec Shield supplies executable markings. Exec Shield only checks for two ELF header markings, which dictate whether the stack or heap needs to be executable. These are called PT_GNU_STACK and PT_GNU_HEAP, respectively. Exec Shield allows these controls to be set for both binary executables and for libraries; if an executable loads a library requiring a given restriction relaxed, the executable will inherit that marking and have that restriction relaxed.

4.3.2 PaX

PaX supplies fine-grained control over protections. It allows individual control over the following functions of the technology for each binary executable:

Executable space protections
- PAGEEXEC
- SEGMEXEC
mprotect() restrictions
Trampoline emulation
Randomized executable base
Randomized mmap() base

See the PaX article for more details about these restrictions.

PaX completely ignores both PT_GNU_STACK and PT_GNU_HEAP. There was a point in time when PaX had a configuration option to honor these settings; that option has henceforth been intentionally removed for security reasons, as it was deemed not useful. The same results of PT_GNU_STACK can normally be attained by disabling mprotect() restrictions, as the program will normally mprotect() the stack on load. This may not always be true; for situations where this fails, simply disabling both PAGEEXEC and SEGMEXEC will effectively remove all executable space restrictions, giving the task the same protections on its executable space as a non-PaX system.

4.3.3 Windows

When NX is supported, it is enabled by default. Windows allows programs to control which pages disallow execution through its API as well as through the section headers in a PE file.

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.

4.3.4 Xbox

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.

5 External links

Computer architecture Computer security

<Hide>

Home > NX bit

1 Hardware Background