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."
Hmm I may be totally wrong here, but ain't this NO EXECUTE thing a responsibility of the operating system?!?
Why implement this at the hardware level, besides "making windows more secure"?
cheers.
``If a program can't rewrite its own code, what good is it?'' - Mel
and it said it's supposed to prevent buffer overflows, and that some are being provided to MSFT for testing ... but WTF is NX, and HTF does it work?
Ok, maybe I don't get this. How is this different from marking a block of memory as data, not code? The real problem is that certain OSes mark all memory as both code and data. Sure, it's easier on the bookkeeping, but it allows buffer overflows. If data was kept in data segments, and code was kept in code segment, the worst that would happen is a corrupted data segment, and/or a General Protection Fault.
Javascript + Nintendo DSi = DSiCade
Because, VBScript viruses come as source-code, and the script engine reads it and executes the functions that the commands want.
.exe attachments, I bet they will still work when the hapless user double-clicks on them.
Or
Or ActiveX holes.. well this would be harder to exploit with the NX feature..
What time is it/will be over there? Check with my iPhone app!
Call me crazy but who wants microsoft software to have anymore to do with their bios..Watch, within a month or two "a virus protection feature" will become an antipiracy/linux feature..
Not to mention the linux people will have to start on a new bluescreen screensaver...
Yes, I RTFA, but can this be used as a DRM measure? If a piece of software is unsigned (as determined by the OS), the processor can be instructed to not execute. Someone smarter than me explain this.
--sig fault--
Doesn't OpenBSD already provide this functionality, on existing i386 processors?
Transmeta To Add 'NX' Antivirus Feature To Forthcoming Chips?
...
Is it me or does this sound like a tremendous failure on the part of operating system vendors, in that this has to be implemented in hardware?
Im sure its more secure but hell, I think this could in the end lead to more complacency in software design. "No need to bother writing secure code cus new chips will have NX technology?" I personally dont even think this will be enough when it comes to the track record of Microsoft anyway.
nick
Electronic Music Made Using Linux http://soundcloud.com/polyp
Why hasnt intel or AMD added NX to IA-32?
Easy. It will give Windows a file system "executable" bit, you know, the one which other operating systems have had for decades, then alter all the software that's already out there to use it.
It's a very clever piece of engineering.
By definition, this about-to-be-executed memory has to NOT be marked NX, or the program could not execute its jump, and would have no way of meandering its way out of the function and back up the stack.
Actually I think he's right. I'm not familiar with x86 ASM, but on other CPUs a stack is a stack... if you can modify the stack, you can make an RTS in the existing code pull a bogus return address off the stack.
If I understand it correctly (I probably don't), stack space would almost always be marked NX anyway. So although we can still change program flow, the real trick is that we can't use memory allocated as stack space to hold the malicious code we want to run. We would have to find or allocate some non-NX memory for that.
Hmm I may be totally wrong here, but ain't this NO EXECUTE thing a responsibility of the operating system?!? Why implement this at the hardware level, besides "making windows more secure"?
Everyone and his brother has heard of the old Motorola 68000 series [it powered the old Macs, and Jobs used the 68040 to power his NeXTSTATIONs and NeXTCUBEs], but Motorola had a very obscure successor to the 68000-series, called the 88000-series, which had a non-von Neumannian Harvard architecture, i.e. it separated the machine code and the data code into two separate physical locations.
Data General built some old multi-processing AViiONs on 88000-series hardware in the late eighties/early nineties time frame; every so often you'll see one for sale on eBay.
Just goes to show that technological leadership is never any guarantee of marketplace leadership - x86 hardware is only now getting some of the features that Data General and Motorola were peddling [without much success] about fifteen years ago.
PS: A number of the guys at Data General who had worked on the gcc 88000-series port ended up over at Red Hat & Cygwin.
Boris Babayan is a Russian chip architect who has never gotten the funding (tens of millions at least are needed these days) to adequately pursue a whole set of interesting ideas of his. He is the guy behind Elbrus, the interesting Russian CPU that never materializes because the money never happens.
Transmeta seems to be based on hiring one of his students, and implementing some version of Babayan's many ideas. Code morphing, protecting code from going out of bounds in hardware, these ideas are originally Babayan's. Maybe they should hire the master not the student, and then things might actually work. It is always sad when people don't realize the students are often not a good substitute for the original. It would be really nice to see Babayan get a shot at doing something in reality.
Of course, I say this without ever having met said student, and I am biased because I did meet Babayan and was personally impressed by him, so take this all with a grain of salt. Maybe I would be equally impressed by the student. Sure would be nice to see Babayan get a try at it though.
If its as good as most BIOS's its trash.
Just goes to show that technological leadership is never any guarantee of marketplace leadership - x86 hardware is only now getting some of the features that Data General and Motorola were peddling [without much success] about fifteen years ago.
Completely unrelated to this is the fact that patents last only seventeen years. I'm sure it's a coincidence though.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Ok, the whole problem started with two decisions.
* Usage of a von Neumann architecture
* Storing call stack in buffer space
And it blossomed from there.
A von Neumann architecture keeps code and data in the same memory space. This means that the CPU can treat anything in memory as code or data - it doesn't care. Further, the software stack which stores temporary variables and return addresses (where to return when a function is complete) is also stored in this same memory area which can be executed. These two decisions provide great flexibility and power in memory management, but with great power comes great responsability.
So a buffer exploit happens like this:
A function is called.
The current address of program execution is stored on the stack.
Any variables the function uses are also stored on the stack after the return address.
Typically stacks grow down from the top of memory and code is stored at the bottom of the memory space.
Then function execution begins.
However, arrays stored in the stack grow upward.
If you store a return address, then put an array right after it of, say, 32 integers, then the 33rd integer is the return address of the code that should be executed when the function completes.
If you store code in the array, then change the return address (at location 33 in the array) to point to the bottom of the array you have your own little function running instead of what the program author intended. Obviously a program that prevents itself from writing outside its own array bounds does not suffer from this particular problem.
The CPU already has an MMU which tracks memory reads and writes into sections of memory called pages. The idea is that the OS can be called if the program accesses memory that is stored on disk, the OS can restore the memory, then it can return to the program. However the OS cannot tell whether the CPU is asking for paged memory because it wants to execute it or merely store/read data in it. Further, the OS may not called at all if the page is in memory since most page faults occur only when memory is on the disk.
The no execute bit is added to each page that the MMU manages. When a program needs more stack space it asks the OS for another page of memory, and the OS, knowing that it's data and not code, sets the NX bit. Then the CPU can report to the OS whenever the program jumps to an address inside the data area, trying to execute that memory as code.
This does NOT eliminate buffer overflows, but it can prevent code execution via overflows. Further, since the OS manages the program stack (for the most part, sometimes through libraries so a recompile may be necessary) then programmer interaction or changes are not needed to make individual programs work under this new system.
Lastly, most OSs prevent writing to code locations (ie, you have to jump through hoops as a programmer if you want your program to self modify its own code as in genetic programming) so by preventing writes to code locations, and preventing execution from data locations then you've eliminated every method that a person could cause the computer to run code that the programmer did not intend to run. This means that further exploits are due directly to the programmer adding code which, for instance, provides an interpreter in their own program (such as with VBScript, Perl, any interpreted language by itself or inside a program) or explicitly sets up an insecure area where code and data can mix and be executed.
-Adam
if you get an overflow on nx page, and the system response is to kill that process, what does that mean for your application? does this mean you should be writing seperate processes for any potentially vulnerable parts of the application so the whole thing doesn't crash? what about in a server situation and your app gets showered with the exploits, dumping all your processes before they can do anything useful?
if the overflow on the nx page DOESN'T kill the process then you need to have some exception code to get the process back to a useable state, which is sizeable itself, if a bunch of processes are doing this all at once...
and how about single process applications? does this mean you can't use non-blocking io any more becasue one exploit will bring it down?
ok, so it is failfast, which can prevent some one running malicious code, but it doesn't give you instant perfect code.
problem: our software is flawed
solution: throw some hardware at it
High-end systems like the IBM AS/400..err, iSeri..err, i5 have had no execute protection for decades. If it's not tagged as a program, it's not executable.
But my point is there are checks that can be performed currently that would avoid these stack smashes. If I can't rely on the programmers to do those checks now, why should I rely on them to properly set this NX bit where and when needed?
Article X: The powers not delegated... by the Constitution...are reserved...to the people
Imagine a Transmeta style firm that can on the fly create microcode for the CPU. You select a random# on microcode creation. Your GNU toolchain then retargets gas to the coding on the ISA. (lets say its x86 permuted in a random way). Now since gas (and binutils) now know the codings a kernel can be built. The kernel, the webserver, RPC statd, whatever are all built using the custom toolchain. Now inject a Linux x86 worm and voila General Protection Fault.
Good luck creating a worm for a "custom" arch.
Hedley
These two decisions provide great flexibility and power in memory management, but with great power comes great responsability.
Using in-band dial tones doesn't have any advantage aside from simplicity. Von Neumann architecture is as simple/complex as any other, it's the side effects we are interested in... So why should we follow suit?
Or, a more mainstream example: one of the main problems with W^X or NX arrangements of late has been Java JIT compilers.
After all, the entire point of a (fast) Java implementation is that it's periodically rewriting its code based on profiling data. That's awfully hard for the hardware to distinguish from a good ol' buffer overflow.
Scheme uses byte-code, so it has nothing with processor. And, after all, it's safe agains buffer overlows :)
Vadim