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."
If they call it the "NX-01", I'm gonna shoot somebody.
Javascript + Nintendo DSi = DSiCade
So how do you turn on this feature? I'd love for "No Execute" to protect me from accidentally running Windows if I choose the wrong option in my dual-boot setup. Will NX be supported by Grub/Lilo?
The NX bit is not an 'antivirus' feature.
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
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!
Just so we're clear here... NX isn't any sort of DRM technology.
It's a pretty smart idea, moving the core concept of "file permissions" into the RAM addressing space. Simply put, if the chip has been told that a certain area of memory has been marked "No eXecute", and then the execution point somehow gets there, an error event is raised to the operating system and that process is killed.
Basically, it's an unreliable but better-than-nothing safety backstop behind unchecked buffers. If somebody manages to exploit a buffer overflow, there's a semi-random chance that the virus code might just crash into being allocated into another area marked NX, and when the execution point gets there the underlying application starts to crash.
Of course, any memory space intended for data and not code should be marked NX... are people going to be smart enough to actually do that when on hardward that supports it? Let's hope so... it'll at least limit the spread of worms.
NX is completely different from NOP.
NX means you can mark a segment of code, well not code but data, as NX [Not Executable]. So lets say I mark some buffer as NX (Because it is just to contain a string anyway) and then someone finds a buffer overflow, and fills my string with some shell code then uses the buffer overflow to jump over to the string's location.
No luck, the shell code is marked NX.
I know you were attempting a joke. But to bring it back on topic:n ol/winxp pro/maintain/sp2chngs.mspx
http://www.microsoft.com/technet/prodtech
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...
It's been awhile since I took Assembly, but from what I understand, NX, or "No Execute", is an instruction that tells the processor to refuse to execute any binary data stored in certain locations in memory. This way, you cannot execute code that might be hidden inside, say, a string variable; this is a common exploit used by trojans & worms called a "buffer overrun", meaning it tries to insert code past the legal length of the string, and, if conditions are right, the code gets executed before the program crashes. I believe that the "NX" feature is found on "Big Iron" processors, and has been for quite some time.
NOP, on the other hand, is "No Operation". Literally, step over this instruction and do nothing. Applications for this are fairly limited, but they do not include attempting to block illegal code from running inside of data space
The "no execute" function is a subset of a call from a governor.
As long as you still have access to "supervisor mode" on your processor (the context the kernel runs in), you'll be able to set the NX flag however you like. Basically, this means that without other measures to prevent you from loading kernel code, all this does is prevent buffer overflows in userland software (and possibly the kernel if the kernel decides to use it, which is probably a good thing).
Now, this isn't to say anything about other mechanisms which would prevent you from loading your own code onto a processor (which is what most of Microsoft's proposed DRM schemes do), but it could close off an avenue of bypassing that DRM (via poorly coded "trusted" software).
It won't. So long as the user insists on granting run permission to something they shouldn't run, it's gonna run.
This only works when the problem is when something is trying to apply the buffer exploit way of taking over the execution point.
Still... just because it doesn't cure cancer is no reason to throw out a cure for the common cold.
"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...
NX is not an instruction at all. it's an extra bit in a page table entry, augmenting the existing read and write bits (among other). once the x86 page table format was decided, it wasn't possible to go back and add a new bit. the introduction of PAE means that the page table entries are twice as big, mostly for larger physical addresses, but an extra bit can be shaved off and used for NX.
Either way, it's nice to see everyone supporting this. Definatly seems like good technology to me.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
the "execute" flag, assuming you are talking about memory protection and not some file permission bit which is unrelated, depends on CPU support. linux supports it on x86 no better than microsoft. if you use openbsd or pax patches, segments or other tricks are used to fake an X bit. but your assertion that ms can't implement an execute flag while linux (especially the stock kernel) can is pretty false.
Here's why:
- To implement this in the OS requires that the OS look up the value of the instruction pointer in an NX table every time it changes pages (assuming that the NX flag operates on a page basis), which would add several clock cycles to every JMP/JR/CALL instruction, and would significantly decrease performance.
- If a basic feature such as this one needs to be implemented by every operating system, it makes more sense to implement it via hardware (the applicable cliche being "Don't reinvent the wheel").
Alternatively, if resources don't have to be dedicated to fixing this problem, those resources can be devoted to fixing other problems. This argument is a little like the argument that, if I want to lose weight, I shouldn't exersize, because I might become complacent about what I eat.It allows you to mark, in hardware, which pages of memory can and can not be exected from. The way it prevents buffer overflows is this:
Application sets up the buffer, and code expoits it to put it's own data into the buffer so it can be executed. But because the page of memory that was holding the buffer was marked NX, the processor won't EVER execute it, it will raise an exception.
So by using this you can make it nearly impossible to exploit buffer overflows in software. You'd have to find software that didn't set the bit. I can see no reason to do such a thing other than some kind of self modifying code buffer, and I would hope people would know better than that by now because if you implement that and let the user pass code, you're just ASKING for bugs.
Linux supports it, I think OpenBSD supports it (other BSDs probably too), Windows XP SP 2 is supposed to support it, I think Solaris supports it, and that's all I know off the top of my head (but that's all the major OSes anyways).
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
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