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.)
Windows has supported that for years.
Why just yesterday it stoped executing for no particular reason.
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.
This "NX" stuff to separate data and instructions is sort of like crossing current CPUs' Von Neumann architecture with a Harvard architecture type of chip, where the storage is actually separate from the executable code.
"AMD's Athlon 64 and Opteron processors have had NX since their debut, though the extra bit won't do anything on a Windows XP system until you obtain and install Service Pack 2. Intel is expected to add NX (or XD) to the next generation of its 90-nanometer-process Pentium 4 "Prescott" CPUs -- bundling the security enhancement with a larger 2MB Level 2 cache and perhaps a faster 1066MHz front-side bus -- in the fourth quarter of this year."
This year has truly been AMD's year to guide the microprocessor market. Remember not so far back when everything AMD did was a response to Intel? This year it's been Intel responding to AMD. I hope this trend continues as it shows that the so-called WIntel stranglehold is starting to crack and that it is possible for the competition to assume a leading role in the market. Now hopefully, IBM has something in the works for it's PPC/Power lines, as they've been working closely with AMD and this processor feature is something that every networked system could use.
Right, all AMD K8-class processors have the NX-bit already. And despite the Intel-centric spin on the ZDNet article, the fact is that Intel has only announced that support for it is coming in future Intel parts. Unlike AMD, it doesn't appear you can buy any CPUs from Intel that support the NX bit today.
... written by Andi Kleen". I.e. NX-bit support was already available to AMD64 owners running 64-bit linux kernels.
In other words, Intel is playing catch-up.
And note the comment in Ingo's linux-kernel posting that refers to the "existing NX support in the 64-bit x86_64 kernels
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.
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!
As a long time happy linux user, but also a kernel author (not x86 though, C80), I can't share your positive attitude towards linux on this issue.
Linus sloppily decided to avoid _almost all_ of the protection mechanisms that the 386 makes available to the system. That's why you can smash the stack for fun and profit. He chose to let CS access the same pages as DS (and SS,ES,FS,GS), whe he could have allocated some linear addresses as code-only, and others as data-only. After that you simply need to ensure that no CS ever was given access outside the executable range, and no other segment was given access in the executabe range.
And you can ensure this - as you, the kernel, are entirely in charge of setting up user-space descriptors.
To do so would have added a bit more complexity to the memory management (with lower case letters) part of the kernel, but would have prevented all smash stacking and heap smashing attacks.
Linux is not _technically_ as good OS at all. It's simply _practically_ (for people like me) a good OS.
Tannenbaum is still right. (And when Tannenbaum says "run 20% slower" he means "take up 0.6% of the CPU rather than 0.5% of it, thus giving apps 99.4% of the cpu rather than 99.5%. But that's another rant.)
FP.
Also FatPhil on SoylentNews, id 863