Slashdot Mirror
Red Hat Introduces NX Software Support For Linux
abertoll writes "In this story at ZDnet, Red Hat has apparently added NX support to Linux. NX security technology is a hardware attempt at stopping malicious code." (We recently posted about Transmeta's announcement that its chips will incorporate the NX bit as well.)
Standard 386 protected mode controls per segment, where CS (code segment) is executable and DS (data segment) is writable. However, many 32-bit operating systems use a so-called "tiny" memory model, setting CS = DS, and the 386 allows for turning off read and write privileges per page but not execute privileges (if you can read a page in an executable segment, you can execute from it).
However, true W^X (shorthand for "no segment is both writable and executable") support won't work for applications that depend on self-modifying code, such as JIT-compiling virtual machines for Java and .NET platforms.
Comment removed based on user account deletion
This new patch is to support NX in 32-bit processors or 64-bit processors running in 32-bit mode.
The 2.6.6 kernel already included an NX patch for x86_64. Details are in the "Non-Exec stack patches" LKML thread here.
People, do yourselves a favor and read the Intel specs. Please? There is in fact, a bit for defining code segments. These code segments can be marked as read only or execute only. The problem (as I managed to wrangle out of people the LAST time this thing was posted) is that a data block can also be executed without exception. The NX flag merely prevents data blocks from ever executing code.
Javascript + Nintendo DSi = DSiCade
NX is not a new thing, and neither Intel or AMD did it first. SPARC's, UltraSPARC's and Alpha's have had this for some time, and it wouldn't surprise me if its in the Power chips as well.
As far as it not being on older processors, I assume you mean older ia32's, and surprisingly this was brought up in a MS TechNet event I was at on Thursday. I don't know all the details, but he presenter said it was in older chips, at least back to the original Pentium if I remember, but with the way ia32 chips do paging, it was never implemented in the OS's until recently, which i can only assume the Athalon64, Opeteron and Itanium do this differently, but don't quote me on that.
Personally, I'm just wondering exactly what ia32 chips will Linux and OpenBSD use NX on.
"I use a Mac because I'm just better than you are."
For the record. Only AMD64 based CPU's currently have support for this on x86. Intel and Transmeta's next generation chips will also support it. No previous CPU's will.
Normal people worry me!
Of course, if those programs were written correctly in the first place they wouldn't need to be fixed to work on NX platforms.
Win32 has always had PAGE_EXECUTE flag, and if you wanted to execute dynamically generated code you were supposed to include this flag when allocating memory (or use VirtualProtect afterwards).
Most people didn't bother with PAGE_EXECUTE because it wasn't enforced on x86. But technically it's always been required.
Linux, Windows, BSD, etc. don't use segments, but instead use paging. Intel has dragged their feet on adding NX support because the feature "already exists", but the reality is that hardly anyone uses segments.
Ok, technically everyone uses segments -- they just create a single segment which covers all of the memory space. The GDT (Global Descriptor Table) must be configured when you switch to protected mode. Paging is optional.
The NX flag prevents a page (typically 4k) from executing. By marking all stack pages as NX, buffer overflow attacks won't be able to remotely execute arbitrary code. I assume that an exception will be generated when an attempt is made to execute from an NX page, which will probably cause the running program to halt. So, remote explots turn into DOS attacks.
Buffer overflow attacks have been known about for decades, and solutions such as NX have been known for quite some time too. As has been mentioned elsewhere on /., this does not remove the responsibility of developers to write good, secure code. But, as history has shown, they will probably continue with the long standing practice of writing insecure code.
NX will prevent buffer overflow attacks. NX will not be able to determine whether a program you choose to execute is good or evil. Viruses existed and managed to propogate back in the days before the Internet or even networking were in common use. NX won't solve all security problems, but it is a good tool to help reduce the possibility of remote exploits.
The NX flag isn't new, it's just new to the x86 world. Kudos to AMD for being the first to add this to the x86!