Slashdot Mirror
Transmeta To Add 'NX' Antivirus Feature To Chips
Autoversicherung writes points to a ZDNet story which says that "Transmeta will support "No Execute," or NX, in their next core revision.
Transmeta will provide advance versions of Efficeon-based systems with NX support to Microsoft for testing. Hope Linus get a few too, even if he's no longer working there.
The NX-equipped Efficeon chips are due for general release later this year."
The NX bit is not an 'antivirus' feature.
Just like Intel developed and implemented the Centrino spec which surrounds and supports the low-power Pentium M in order to compete in the wireless/ultraportable arena with products incorporating the Crusoe and the Efficieon, you can expect they'll have something up their sleeves with regards to this. I mean, it's not like they're just sittin' alone in their parents' basement watching Buffy reruns, and spanking it to naked Portman pictures.
The theory of relativity doesn't work right in Arkansas.
Because any time you're allocating memory for yourself, the OS isn't quite sure just what you're going to put there. When it's assembly-written code, the OS really can't tell the difference between the load of more code and the load of data.
Besides, what if the buffer exploit is inside the operating system itself? Even Linux could fall victim to that kind of mistake. We've found that as long as bad code is distributed, somebody will still be running it long after the issue has been discovered and patched, and there's been worms to prove it.
How exactly is this an anti-virus feature? Anti-buffer-overflow, yes. Anti-worm... well, maybe, but it'd be a bit of a stretch (anti-worm-based-on-buffer-overflow rather). Anti-virus? Hell no.
I just love tech journalism...
doesn't this required the software to be rewritten to use it? I think it would make much more sense if NX were replaced with something in the os that didn't automatically allow software to be installed by clicking "OK" on some web page. Even though it's annoying to have to type in the root password constantly in Linux, it's a hell of a lot easier than reformatting and reinstalling as I've done for too many people. Even if the computer is operated by one user, this requirement of the root password still makes them more aware that something is about to modify their system. Those activeX dialog boxes in IE make it seem like gator is a new and exciting feature and that's why people install it so much.
"No need to bother writing secure code cus new chips will have NX technology?"
I don't think that this segment of the programming population falls into those kind of pitfalls very often.
I know at least one other post called it a "fallback" measure, which sounds about right. It's a third line of defense against buffer overflows and the like (the first being good programming practices, the second being things like libsafe).
Sure, it is also helpful towards Microsoft; I can see how it restricts circumvention of DRM. But there are always other ways around. If you overflow into a buffer not protected by NX, you still have arbitrary code execution on your hands.
Of course, this is just what I get from the other posts and intuition. It's not like I RTFA or anything...
Granted, I haven't really paid much attention or done any research on this no-execute flag, but it seems to operate within the data structures of a program such that you can flag a structure, memory block or references to it as non-executable.
If that's the case they how effective can this really be at stopping buffer overflow attacks, we still need to rely on the programmers to tag every data structure as non executable (and that isn't easy). We're talking about the same programmers who don't validate input data or put limits on it.
So basically, fixing a human problem in hardware is no solution. no?
Or is it that by default, nothing is executable unless you specifically tag it to be, so that the system by default won't run anything it loads?
Article X: The powers not delegated... by the Constitution...are reserved...to the people
I wonder why Intel is unable to use this functionality in conjunction with the current version of Windows to prevent introducing executable code via stack overflows?
Best Buy can have you arrested
nx is a flag on a page (or block) of memory that indicates to the processor that i shouldn't be executed (page address not loaded into the ip?)
i can see that this would help catch some programming errors in a similar fashion to marking page 0 as read only (this catches all the bad offset references and unassigned pointer references). of course this would only really work if your compiler marked memory nx in a proper fashion.
i can see how this might help prevent buffer overflow attacks (worms), except that code should be marked read-only anyway... i'm kinda iffy on this.
but how in the world is this going to do anything to prevent a viral attack?
eric
That could be true, if the buffer were placed right before an executable chunk. But it never is. Variables are allocated on the stack, not in code space. Heap memory is often allocated near the stack, but again not in code space.
When a program calls a function, it stashes a return address on the stack. This address specifies where execution should resume after the function returns. If an exploit can overrun the stack, the exploit overruns this return address! So an exploit will fill a buffer, run off the end of the buffer, put an address on the stack right where it overwrites the return address of the current function, and possibly then overrun some more. If there is a function embedded in the overrun (either on top of the buffer, or after the return address) the address of that function is used to overwrite the return address. So when the function returns, that function runs. A small amount of code can act as a bootstrap loader that loads the rest of the exploit.
Here's a primer on how to write a basic stack smashing local root attack. I just found this with Google.
http://community.core-sdi.com/~juliano/htce.txt
Here's the text of a comment from the sample code:
Emphasis added by me. "executed on the stack"... in other words, this exploit would not work if the stack were marked NX, like I said.
Can you find me an article about how to execute a stack-smashing attack, where the exploit actually blows past the end of the stack or the heap and somehow winds up in normal code space? I have never heard of any such. Can you find even one example of the technique as you describe it?
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
There are such attacks, but they are extremely subtle. Basically, instead of jumping to their own code on the stack, they write a different overflow which patches in a call to exec(). (Unix only, but on a Windows box, ShellExec will do just as well.) Hey presto, direct shell.
This wouldn't work w/ a language like scheme. Procedures are frequently created and/or modified at runtime.
Duh, build an Althon64 system.
Did you see the part where I said I wanted it to be silent? As in, passive heatsink only? Athlon64 need not apply.
That said, my next desktop computer will be an Athlon64, because I can make it pretty quiet and it will run Doom III pretty well. I'd just like to have another computer that's silent, and use that for email and such. Then I can power down the Athlon64 when I'm in the mood for total silence (and not playing Doom III).
By the way, you say "VIA's crap" but I really love my tiny, quiet little Mini-ITX servers with VIA C3 chips. Great for email servers, file servers, etc.
Not every computer needs to run Doom III.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Actually, it's per page, not per segment. Segments had an exec flag from 32bit day one and this was the card Intel hoped people would play[*]; they were mostly wrong though, the segment-level protection did not get used so much.
[*] there are several such examples of stuff in the hardware that never got used on x86 - full use of privilege level granularity comes to mind; afair one of the reasons invoked against all these goodies Intel came with was portability.