Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Executable-space protection
In computer security, executable-space protection marks memory regions as non-executable, such that an attempt to execute machine code in these regions will cause an exception. It relies on hardware features such as the NX bit (no-execute bit), or on software emulation when hardware support is unavailable. Software emulation often introduces a performance cost, or overhead (extra processing time or resources), while hardware-based NX bit implementations have no measurable performance impact.
The Burroughs large systems, starting with the Burroughs 5000 introduced in 1961, implemented executable-space protection using a tagged architecture. All accesses to code and data took place through descriptors, which had memory tags preventing them from being modified; descriptors for code did not allow the code to be modified, and descriptors for data did not allow the data ta be executed as code.
Today, operating systems use executable-space protection to mark writable memory areas, such as the stack and heap, as non-executable, helping to prevent buffer overflow exploits. These attacks rely on some part of memory, usually the stack, being both writable and executable; if it is not, the attack fails.
Many operating systems implement or have an available executable space protection policy. Here is a list of such systems in alphabetical order, each with technologies ordered from newest to oldest.
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.
As of Android 2.3 and later, architectures which support it have non-executable pages by default, including non-executable stack and heap.
Initial support for the NX bit, on x86-64 and IA-32 processors that support it, first appeared in FreeBSD -CURRENT on June 8, 2004. It has been in FreeBSD releases since the 5.3 release.
The Linux kernel supports the NX bit on x86-64 and IA-32 processors that support it, such as modern 64-bit processors made by AMD, Intel, Transmeta and VIA. The support for this feature in the 64-bit mode on x86-64 CPUs was added in 2004 by Andi Kleen, and later the same year, Ingo Molnár added support for it in 32-bit mode on 64-bit CPUs. These features have been part of the Linux kernel mainline since the release of kernel version 2.6.8 in August 2004.
Hub AI
Executable-space protection AI simulator
(@Executable-space protection_simulator)
Executable-space protection
In computer security, executable-space protection marks memory regions as non-executable, such that an attempt to execute machine code in these regions will cause an exception. It relies on hardware features such as the NX bit (no-execute bit), or on software emulation when hardware support is unavailable. Software emulation often introduces a performance cost, or overhead (extra processing time or resources), while hardware-based NX bit implementations have no measurable performance impact.
The Burroughs large systems, starting with the Burroughs 5000 introduced in 1961, implemented executable-space protection using a tagged architecture. All accesses to code and data took place through descriptors, which had memory tags preventing them from being modified; descriptors for code did not allow the code to be modified, and descriptors for data did not allow the data ta be executed as code.
Today, operating systems use executable-space protection to mark writable memory areas, such as the stack and heap, as non-executable, helping to prevent buffer overflow exploits. These attacks rely on some part of memory, usually the stack, being both writable and executable; if it is not, the attack fails.
Many operating systems implement or have an available executable space protection policy. Here is a list of such systems in alphabetical order, each with technologies ordered from newest to oldest.
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.
As of Android 2.3 and later, architectures which support it have non-executable pages by default, including non-executable stack and heap.
Initial support for the NX bit, on x86-64 and IA-32 processors that support it, first appeared in FreeBSD -CURRENT on June 8, 2004. It has been in FreeBSD releases since the 5.3 release.
The Linux kernel supports the NX bit on x86-64 and IA-32 processors that support it, such as modern 64-bit processors made by AMD, Intel, Transmeta and VIA. The support for this feature in the 64-bit mode on x86-64 CPUs was added in 2004 by Andi Kleen, and later the same year, Ingo Molnár added support for it in 32-bit mode on 64-bit CPUs. These features have been part of the Linux kernel mainline since the release of kernel version 2.6.8 in August 2004.