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.
I am pretty sure you dont need to recompile code to use NX, the OS allocates stack space to your program and hence knows what data to flag as NX. Now, if your program executes code on the stack by design, then you will have a problem. Nate
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.
Well, memory you grab in Linux with malloc(...) and friends isn't *supposed* to be executable, though some applications (XFree86 comes to mind, amongst others, not to bash XFree86) think that it is.
This is why using NX and friends on Linux can break apps. Any application that loads code into memory it grabbed with malloc or similar will get killed when it tries to run code in that memory space (since that memory isn't supposed to be executable).
Now, there are ways around this of course. The proper way is to fix the application to either not use malloc for grabbing storage for things that are supposed to be executable or to include an option when calling malloc to say "yeah yeah, but I need to this to be executable too", though that sounds kinda hackish.
The way it's currently implemented with software implementations of NX are to provide a userspace tool to mark an application as "broken" or whatever and therefore exempt from NX checking. Silly and insecure, but it works.
As I understand it, the IA-32 architecture does not support NX. I don't think you could just tack it on as an afterthought and have it work.
There are some kernel patches such as grsecurity which do emulate this functionality in the kernel, but that brings performance down.
Can I get an eye poke?
Dog House Forum
Maybe I'm just being dense here. :-/
To clarify--what the parent is saying is that x86 doesn't have an execute protection bit (at least up until this "NX" thing). Therefore, you can't mark pages execute-only; your only choices are read (and execute) only, write only, read (and execute) and write, or nothing at all.
In any case, you're missing the point of the original discussion, which is that being able to write to executable pages is what's bad, and the x86, lacking an execute protection bit, can't prevent overflowed buffers in data and stack areas from being executed. I'm not sure what you'd gain from marking executable areas unreadable, and you'd undoubtedly break lots of programs that keep constant data (strings, etc.) in code space.
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
In this case, though, that's a red herring. The jump in most buffer overruns is into the stack itself. The BO allows the attacker to overwrite the return pointer -- and the stack starts at a fixed address, so the attacker can compute the address to return to. Yes, you could move the stack's root around, but that only reduces the probability of success of a single instance of an attack. It doesn't prevent the attack in all cases. Most attackers are willing to try thousands of times to make an attack succeed if that's what is required.
(And, again, there's nothing special about Windows here. Linux and even OpenBSD make the same choice. As I said, the actual security benefit of moving the stack is very limited. The perf consequences, by contrast, are drastic.)
It isn't true to say W^X is weaker -- only the i386 (and PPC) versions are *weaker* because the chip doesn't have the ability to protect individual pages. On architectures with this feature, OpenBSD takes full advantage.
Star Trek. It's the ship tag of the ship on the show Enterprise.
- It's not the Macs I hate. It's Digg users. -
The new Efficeon isn't top-of-the-line by any standards, but it isn't dead yet either. Don't believe everything Van's Hardware says about Transmeta, or even about CPUs in general.
For example, he also fails to mention that the C3 does AES (and only AES) in hardware. He seems somewhat surprised at its AES performance in his (suspiciously chosen) AES benchmark, despite the fact that he works for them (Centaur)...
pb Reply or e-mail; don't vaguely moderate.
Back in 1997, Solar Designer released a kernel patch which marked the stack in linux as non-executable. However, the x86 processor did not allow individual pages to be marked as non-execute, which prevented marking non-stack
data segments as non-executable.
There were some problems with GCC's generation of executable code on the stack for (non-standard C) calls to nested functions. The workaround for
that weakened the security of the patch a bit.
And there may occassionally be valid reasons to write self-modifying code; hopefully, those can
be done in a special segment that doesn't have
its execute permission revoked by the loader.
http://www.openwall.com/linux/FAQ.shtml
Yes, they do. Why does everyone insist that they don't? I was reading about the execute vs. data segments back in the days of 386s!
Here's the manual if you don't believe me.
Javascript + Nintendo DSi = DSiCade
Modern OSes set up the code, data, and stack segments to point to the same region of memory, and programs expect to be able to access the entire 32-bit address space without needing special kinds of pointers (aka the joys of near, far, and huge pointers in old DOS programs.)
Thus, the only practical way to make the code segment non-executable is to try and move all code to the bottom of memory, and basically prevent the rest of the 32-bit address range from ever being executable. Many programs don't work under this restriction (such as programs that dynamically load or create code at runtime.)
What people are talking about here is the ability to mark any page in memory as being non-executable, which allows the OS to avoid using a huge sledgehammer to fix the problem.
dtach - A tiny program that emulates the detach feat
Ok, you're right you got me. /me smack head
But what I meant to say was the page table entries don't have an execute bit, which is what I believe the NX flag is, for cases where the OS was designed with 4gb flat selectors for CS/DS. This would allow (with much less modification to applications/system) page-specific protection against execution.
Send lawyers, guns, and money!
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?
What? Transmeta is a modern processor.. it didn't support marking pages as non-executable? Can't believe it.
:)
Actually NX-feature is not new. Sparc, Motorola etc had it for ages. Even x86 allows to mark "segments" as non-executables (famous Linux patch uses it to prevent most buffer overflows). The problem was that i386 didn't allow to mark _individual_ page as non-executable (NX), only a segment.
Think about it as a bug fixed.
All the rest is just a marketing.
And, of course, it will not stop your favourite email worm
Vadim.
Wow, news spread fast. I know the guy you're talking about personally (I work at Elbrus) so I wanted to add some corrections. Transmeta is not based on hiring him. There is a difference between Transmeta and Elbrus, you can know the path (Elbrus) and you can walk the path (Transmeta). It's a big difference. Transmeta is already on the path and has made a long way so it has way more expertise than Elbrus. That guy is just adding more knowledge, it's not that his is an exclusive source of Transmeta growth.
Besides (pardon my non-native english) the word student sounds strange. He is not very young and he's not studying. He was rather gathering all knowledge and ideas by working with bright people. I'd say he was a high profile worker here.
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.
This isn't the problem it first appears. All you have to do is generate the JIT'ed code into a region of memory not marked NX. It should only be a minor addition (if needed at all) to whatever code allocates the memory for JIT'ed code, like using mmap with the PROT_EXEC flag set.