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.
... NX support is not an excuse to write potentially unsafe code.
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
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?
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.
I'm Captain Jonathon Archer of the starship, Red Hat Enterprise, NX-01 class security. ;-)
It is impossible to enjoy idling thoroughly unless one has plenty of work to do.
- Jerome Klapka Jerome
"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.
Yes, I sincerely agree. Unfortunately this usage error of the word is now so widespread, I fear nothing can be done anymore.
Looks like only the wise understand the distinction among "tool" and "feature" and and "technique" and "technology", but the rest of the people who gather their world knowledge from buzzword driven press articles will keep thinking that Visual Basic is a "technology" as well as Java.
Actually it would be interesting to discuss how the scopes of these 3-4 concepts should be in the area of computers.
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.
The malicious code is the code which runs in an area of memory where it shouldn't be (meaning executes a buffer-overflow attack).
Considering the current Linux architecture, I really don't see a problem with what's proposed... especially if the chances of breaking things are almost nill. Doesn't seem a far stretch due to the way things currently run in Linux anyway. Developers can work around any problems that may arise anyway. This will help to ensure that Linux remains one of the most promising operating systems available, and even moreso than it is already.
I saw mention in the linked article that Microsoft plans NX support in their SP2 release for Windows XP, but seriously... I don't see this as either happening in the first place, or having the potential to really screw things up. Won't this break a huge amount of applications? Think about it, the Windows platform is notorious for allowing programs to execute whatever code they like... even going so far as to say that some rely on that ability. Any thoughts on this?? I just don't see it happening with the current architecture, that's all.
Linux with kernel panic...
MadPenguin.org
The PaX patch effectively implements this feature on older x86 processors that don't have hardware NX support. It takes advantage of the fact that data and code have separate page table caches.
It comes with a pretty high performance overhead, though. A page fault will occur for any miss of the TLB cache while normally they are just loaded from the page table in main memory.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
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.
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.
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.
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"
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.