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?
I personally can't wiat until some great evil makes a virus harnising NX to say.....block the execution of MSIE .....widespread luser panic is always fun
-- Checking emails and kicking cheats `till the day I die.
And I always wanted processor support for the Evil Bit. Dang.
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.
Karma: Segmentation fault (tried to dereference a null post)
... all those fellow /.'ers who cried out loud "we don't want no DRM" when they first read the titles of the stories about NX support in upcoming procs, without even bothering to understand WTH NX is for, and kept and kept writing idiotic comments about how evil Windows must be because it now supports NX (which they seriously thought was some form of ah-so-evil DRM feature)
:) I am happy that you will now have an opportunity to open your minds to this fine new technology.
See, NX is a good thing, now even Linux has support for it
Cheers.
Seriousely, the NX stuff is a "good" thing to add to slow down malicious code - the only thing better would be a HULK Instruction which would SMASH Puny Human malicious code ... ;-)
Hulk SMASH Celiac Disease
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.
This is all well and good, but is certainlly not a panacia.
No execute means that somewhere, somehow there will be an override and the day the override is used the virus' will follow by tricking (and explaining how) to the user why this is needed and bingo, it's in.
And of course I could be completely wrong in that this no execute bit does not exist on older processors and that in itself is going to cause problems. Intel has xbit on newer processors, but what about AMD, VIA, whoever else? Is this part of the Intel half of the WinTel duopoly?
I think it's probably a good idea, but I'm suspicious.
Comment removed based on user account deletion
Calling it a "technology" I suppose detracts from the fact that the lack of an executable bit in x86 page tables is a deficiency. You see, this "feature" has been around since, oh, the middle of the last century, and many processors other than x86 have supported it without even considering it worth mentioning.
"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.
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.
Some legitimate programs, such as Java compilers that perform just-in-time code generation, execute instructions within data areas -- and will have to be rewritten for Service Pack 2. But the most common exploiters of x86 architecture's porous program and data boundaries are applications (called, as a matter of fact, exploits) that perform buffer overrun attacks -- one-two punches that first flood a program's input area with more data than it's designed to handle, then deliver a poisonous executable payload. ..........
Software developers will be able to selectively disable execution protection for 32-bit applications, using a DisableNX fix in SP2's compatibility toolkit, and end users will be able to switch the feature on and off for the entire system or for individual applications (like those Java compilers) via a new Control Panel dialog box, similar to those for SP2's beefed-up firewall .
Now it is time for you, young grsshopper, to learn as well.
translation:
Malicious code executing itself via a buffer overflow is actually one of the lesser evils in the virus world. Most users will gladly allow anything to run on their box, especially if it does something cool (time, weather, cutesy things, etc), and with everyone being root on Windows boxes, this means the program can do whatever the hell it wants and windows won't say anything/much.
The NX bit is great, especially for servers where generally the only kind of attack is a buffer overflow. Like I said the procesor has learned well, but the users must learn also.
md5sum
d41d8cd98f00b204e9800998ecf8427e
This is basically an "execute / no-execute" bit in the page-table entries. It means the OS can mark portions of an application's virtual address space as non-executable - such as pages in the heap or the stack. It'll help against buffer-overflow attacks that put new assembly code in the stack and return into it. It won't help against buffer-overflow attacks that return into existing code (e.g., to do a system call). It won't help against worms that take advantage of meta-character expansion vulnerabilities. It won't help against scripting flaws (such as javascript, active-x, or visual-basic/outlook vulnerabilities). It won't help against weaknesses in the OS itself.
Think of this as raising the bar. Of course, the "clever" attackers will still find flaws, and still write code for the script kiddies to use to exploit them.
From what I've read, it certainly makes sense to break a few apps for this functionality, as you can always run them in a build without it. Things should be a lot safer, as crap like buffer overruns from carefully formatted input strings can no longer contain executable code.
I think this should be available for individual programs to set the NX bit on memory pages that should only contain data, so, for example, when you download a file, it is impossible to execute it (say, while in memory) until you save it and explicitely set the execute bit. In other words, there is a completely non-executable path for all untrusted code from its inception until the user explicitly makes it run. Now, when some Joe Luser clicks an email attachment virus made for Linux, if this ever happens, it will be very difficult for him to make it run, and hence, it won't. Add to that the protections inherent in all Linux systems (multiuser permissions, heterogeneous configurations, etc.), and it's very unlikely that Linux users will experience the kind of crap that Windows users have to put up with on a daily basis, even if Linux somehow gains a huge market share on the desktop.
These are exciting times.
There's some history of self-modifying code from the 16-bit DOS world, but it's probably time to kill that off.
It's been a long time since self-modifying code improved performance. Today, self-modifying code on an x86 machine works something like this.
So, in general, self-modifying code is not going to help performance. Generating blocks of code and then making them executable is fine, but changing code you're about to execute went out with "ALTER paragraph-name TO PROCEED THROUGH paragraph-name" in COBOL.
Under Linux at least you can ask for executable mapped pages. This is what the fixed X loader does for x86 now. Most non x86 processors have execute bits on page table entries and POSIX/SuSv2 therefore have a MAP_EXEC bit in mmap so you can say "I want to run this"