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.)
What I fail to understand is the difference between this 'no execute' bit and the 'executable' bit in standard 386 protected mode. Does the 'executable' bit not cause an exception if the PC proceeds to pages without it set? Even then, protected mode also has a 'read-only' bit - isn't this set for code pages? And if not, why not?
Yes, I do. It was a JOKE. You really want me to spell it out for you? I was implying that I'd been hacking Slashdot regularly but now the new NX protection was stopping me. Happy?
Karma: Segmentation fault (tried to dereference a null post)
How would Just-in-time compilers and interpreters work? If I understand this correctly, you can't write data to executable areas of memory, but then how do you run instructions that are written to memory!?!? Could someone explain?
"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
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.
data char* temp = new data char[len];
executable char* code = new executable char[len];
int function() = code;
compile(javasrc, temp);
copy(temp, code);
function();
From what I've heard, allocations will default to non-executable, but there will be some sort of API that allows executable space to be allocated on every OS that deals with NX bits. You will probably also see WinXP and the like with the ability to "Run this program in compatibility mode..." until the developer updates to deal with the tweaks made in the updates.
compile(javasrc, temp);
copy(temp, code);
function();
And watch as NX::copy() has a huge overhead from going into kernel space and back.
This, to me, seems like just one more slow, inexhorable step towards "Trusted Computing".
Why do we need a per-page NX bit if the write and execute permissions are already set for the segment?
Even on the 286 (running in protected mode), code segments are executable, but cannot be writeable, and non-code segments can be writeable, but not executable. I think that's basically what you want - non-executable data, and non-modifiable code (of course, the code needs to be written to memory once, but you can make it non-writeable before starting execution).
So how come we also need an NX bit on pages (knowing that pages can only be accessed if there is a segment that references them)? Do our operating simply ignore the security that the segment permissions provide, and if yes, why? Why is per-page control so much better than per-segment control?
Please correct me if I got my facts wrong.
Yep true. I know one compiler that used "thunks" (small sections of runtime generated code) to make multiple inheritance as efficient as single inheritance code (the Zortech C++ compiler). Probably what I was thinking of.
Grsecurity/PAX users have had this on ALL the platforms for couple years already.
Grsecurity/pax has had a few hundred more security enhanchement improvements over the stuff the articles now here are talking about. So what's the fuzz? Hah.
Btw, the development of Grsecurity (which is the best [most secure, most effective, easiest] way to make Linux platform secure) stopped already and the project will officially die tomorrow due the lack of sponsors.