Red Hat Introduces NX Software Support For Linux 188
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.)
Difference between NX and protected mode bits? (Score:3, Interesting)
Re:Darn. (Score:1, Interesting)
JIT Compilation/Interpreters (Score:2, Interesting)
AMD once again taking the lead. (Score:5, Interesting)
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.
Re:Fine No Execute (Score:5, Interesting)
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
Re:Per-segment vs. per-page (Score:5, Interesting)
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.
Re:Difference between NX and protected mode bits? (Score:2, Interesting)
This is why linux is so efficient; bugs are corrected in the kernel and recompiled for the new releases. It's a much better solution that adding code bloat or processor overhead to solve these types of issues.
--
Smack your momma good deals!: http://www.dealsites.net/livedeals.html [dealsites.net]
Re:Per-segment vs. per-page (Score:3, Interesting)
compile(javasrc, temp);
copy(temp, code);
function();
And watch as NX::copy() has a huge overhead from going into kernel space and back.
One step at a time (Score:1, Interesting)
Can someone explain... (Score:3, Interesting)
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?
Re:What about C++ vtables? (Score:2, Interesting)
Re:Difference between NX and protected mode bits? (Score:5, Interesting)
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.
This is just a marketing gimmick (Score:2, Interesting)
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.
Re:Can someone explain... (Score:3, Interesting)
Well, yes, that's what they would use if the x86 let them. As it is, a segment is either code (and thus executable, but not writeable), or data (not executable). This means that they must use different descriptors, and hence different selectors for each. From there, it seems a small step to have the segments not overlap, thereby disabling applications from writing to their code segment. Not doing this seems like ignoring a perfectly good security mechanism.