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."
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
I hope they consider sending one to the OpenBSD project -- considering OpenBSD has been sort of a pioneer in this kind of buffer-overflow protection (the first and only OS so far to include it by default, and have done so for about 1.5 years now).
It would seem like a logical (and swell) thing for Transmeta to do
It can be done in software (grsecurity does it on x86 in linux), but is much faster if done in hardware (and I believe linux makes use of it already on those archetectures which support it such as Alpha and UltraSparc).
There is significant overhead in doing it in software since you need to check the NX flag every time you bring up a page of code to execute. If it's done in hardware, you don't need to even do a context switch on many archetectures, and the hardware will just throw an exception if something bad happens (trying to execute code marked not executable), which the kernel will catch and handle (likely by segfaulting the offending process). Possibly remote root hole turns into a trivial DoS attack.
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
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).
Yes, but it's using segments, which are separate from regular virtual memory and paging. This will be easier for OS developers to use, and will be cross platform (at least with other architectures that support NX... sparc, etc). Segments are an x86-only feature.
My server
The OS isn't the problem, most OSes already keep code and data is separate segments. The problem is the x86 chip, which has no separate execute permission bit for memory, and assumes that anything that's readable is also executable. This makes it hard to protect random pages on the x86. The no-exec patches for x86 use various tricks to try and work around this limitation, but it's still not as good as having a separate execute bit per page of memory.
dtach - A tiny program that emulates the detach feat
Hmm I may be totally wrong here, but ain't this NO EXECUTE thing a responsibility of the operating system?!?
Unless it's Palladium, the operating system doesn't care what's running in user space beyond what it needs to know about to ensure operational integrity. A buffer overflow in an application doesn't compromise the OS, it compromises the application -- and even if it wanted to, the OS likely wouldn't even be able to tell with any reliability that something illicit was happening in the process. The NX flag is a way of letting the OS know how to know if things go sour.
NO CARRIER
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.
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.
The no-exec stack patches use a huge sldgehammer to try and work around this limitation. All code is moved to the very bottom of the 32-bit address space, and the code segment is limited in size (normally all segments can see the entire address space.) However, it is not always possible to do this flawlessly, and many programs don't tolerate it well.
dtach - A tiny program that emulates the detach feat
What you're suggesting is irrelevant to the discussion at hand. Being able to create execute-only segments is fine for code, but doesn't really work for the stack. A thread's stack must be readable and writable by the process, right. Therefore, on an x86, was required to be executable. Oops -- that means you can jump to an address on the stack and run code there.
http://www.microsoft.com/technet/prodtechnol/winxp pro/maintain/sp2chngs.mspx
Forget the whales - save the babies.
That reference does not mention marking something as NOT execute. I think the document does not go into enought detail in permissions. I saw a mention above and someone wrote that if the CPU could read the data, it could execute it. If that is correct then setting data/read-only on a segment does not preculde it execution. -Nate
It's a general anti-buffer-overrun feature (among other things) that patches some of the holes commonly used by viruses and worms to escalate privileges. That's very anti-virus, in that it will make it more difficult to write the critters. It is not exclusively useful for blocking viruses, but I don't think that anyone was making that argument.
Dewey, what part of this looks like authorities should be involved?