Transmeta To Add 'NX' Antivirus Feature To Chips 265
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."
Enterprise Computing? (Score:5, Funny)
Re:Enterprise Computing? (Score:5, Funny)
Or maybe I'm from a parallel universe...
Re:Enterprise Computing? (Score:3, Informative)
I didn't RTFA, but (Score:2, Troll)
Re:I didn't RTFA, but (Score:5, Informative)
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.
Re:I didn't RTFA, but (Score:5, Informative)
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
Re:I didn't RTFA, but (Score:4, Informative)
mod parent down (Score:2)
Has nothing at all to do with instructions, except that you can't execute instructions in a data segment with the NX bit set.
Re:mod parent down (Score:3, Insightful)
[*] 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.
ok, i see part of this... (Score:3, Insightful)
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), ex
Re:I didn't RTFA, but (Score:4, Funny)
Microsoft certainly knows about NOP though...
Re:I didn't RTFA, but (Score:5, Informative)
No Execute? (Score:5, Funny)
Note to editors (Score:5, Insightful)
Re:Note to editors (Score:4, Informative)
is this worth it? (Score:4, Interesting)
Why implement this at the hardware level, besides "making windows more secure"?
cheers.
Re:is this worth it? (Score:5, Insightful)
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.
Re:is this worth it? (Score:3, Interesting)
This NX thing sounds like just a bunch of hoopla to make Microsoft start doing their job. Unfortunately, I don't think Linux is much better.
Re:is this worth it? (Score:2, Informative)
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 i
Re:is this worth it? (Score:2)
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).
There are plenty of dumbly-written Windows apps that have th
Re:is this worth it? (Score:2)
On Intel chips there is no way to tell the difference between memory that can be read, and memory that can be executed. That means your memory can be executed by any program that ca access it.. The only way around this is to mark the memory as not readable, and trap all accesses to it, and let only the ones that are reading the memory though. It would work, but your gigahertz computer would operate at about the speed of a 286 do to all the checking that needs to be done all the time.
Re:is this worth it? (Score:2)
Incorrect. Read Section 3.2.3 "Multi-segment Model" of the "IA-32 Intel® Architecture Software Developer's Manual: Volume 3: System Programming Guide". It lists both data and code segments quite clearly. This stuff has been around since the 386 days.
Re:is this worth it? (Score:2)
Re:is this worth it? (Score:3, Informative)
Here's the manual [intel.com] if you don't believe me.
Re:is this worth it? (Score:3, Informative)
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.
Re:is this worth it? (Score:5, Informative)
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.
Re:is this worth it? (Score:5, Informative)
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.
Re:is this worth it? (Score:2, Interesting)
Data General & the obscure Motorola 88000-seri (Score:4, Interesting)
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.
Re:Data General & the obscure Motorola 88000-s (Score:5, Interesting)
Completely unrelated to this is the fact that patents last only seventeen years. I'm sure it's a coincidence though.
I did RTFA (Score:2, Interesting)
Re:I did RTFA (Score:2)
But then again, I know absolutely nothing so I may be completely wrong.
Re:I did RTFA (Score:2)
Then it would pass from a data segment into a code segment. If it passes into a code segment, the processor will throw a general protection fault. The OS will catch the General Protection Fault and kill the program. Keep in mind that standard mallocs should only be returning data segments of memory. So (in theory) the overflow can't be writing to execute memory.
Re:I did RTFA (Score:2)
Also, GPFs are "General" protection faults. The concept itself is not tremendously descriptive on what circumstances it's thrown. Under Unix, they referred to it as a "segment violation".
Re:I did RTFA (Score:5, Informative)
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).
How is this different? (Score:5, Interesting)
Re:How is this different? (Score:5, Informative)
Re:How is this different? (Score:2)
My understanding is that the real issue has been supporting self-morphing code. Since a lot of legacy code liked this performance trick (especially games), all segments were marked as data and code.
Re:How is this different? (Score:3, Informative)
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 do
Re:How is this different? (Score:2)
But that's my point. You shouldn't *need* to make code memory readable. Mark it as 100b, and make sure that the only register that references it is the Instruction Pointer. The processor will still get its instructions, and the OS will be safe and happy.
Maybe I'm just being dense here.
Re:How is this different? (Score:3, Informative)
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 pr
Re:How is this different? (Score:2)
The manual says that you can have an execute only segment as long as you load the executable constants into some other segment. (Or alternatively, m
Re:How is this different? (Score:4, Informative)
Re:How is this different? (Score:3, Interesting)
Parsing...
Ok, I think I've got you now. Correct me if I'm wrong though, but isn't that a problem with the way that Windows executable are directly mapped to memory? IIRC, the SP register takes a selector. That selector should be able to point to any location in the GDT or LDT table. Hmmm... let me check my
Re:How is this different? (Score:3, Informative)
Nope, although it might seem that it would matter. (BTW: absolute mapping of critical OS entry points is enforced in most operating systems. Invoking the loader to relocate OS entry points breaks a lot of things...like the loader itself.)
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
Re:How is this different? (Score:2)
Ding, ding, ding! I think I've got it. You're saying that the stack is set to point to a relative address so that the CPU doesn't have to use a long pointer to access the stack. Use of a shorter pointer improves performance drastically because the CPU is saving itself quite a few lookups and offset computations. Right?
Re:How is this different? (Score:2)
Re:How is this different? (Score:2)
Re:How is this different? (Score:2)
The problem is that there are historical and legitimate reasons for executing "data" and so OSs allow it. I remember in CS 121 when we had to write a just-in-time x86 assembler. We read in the assembly code and generated byte code into an array. Then we just cast the array (pointer) as a function (pointer) and called it, like any other function. There are other cases where self-modifying code is used. This was in linux, so it isn't a problem with just "certain" OS's.
Furthermore, I m
Re:How is this different? (Score:2)
The problem is that there are historical and legitimate reasons for executing "data" and so OSs allow it.
Which is where the NX flag won't help. You *still* need a way of telling the OS whether a segment should be executable or not. What the OS should allow is to allocate a data segment for code loading. Once loaded, a special kernel method is called to switch it to execute-only. That would support JITs, and prevent buffer overflows.
Furthermore, I may be wrong here, but I don't think the original x86 h
How well will this work against VBScript viruses? (Score:5, Interesting)
Or
Or ActiveX holes.. well this would be harder to exploit with the NX feature..
Still useful (Score:2)
Re:How well will this work against VBScript viruse (Score:5, Informative)
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.
So simple, we might as well do it. (Score:5, Informative)
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.
Re:So simple, we might as well do it. (Score:2)
Oh, it's a bit better than that. I believe most buffer overrun exploits put code into the buffer overrun. If the buffer is allocated on the stack, and the buffer a
Re:So simple, we might as well do it. (Score:2)
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.
NX may be useful, but it won't end buffer overruns. There are only really two ways to do that: strn* or a
Re:So simple, we might as well do it. (Score:4, Informative)
he was exactly right, you are a little right, but much less right then him :) Buffer Overflows work by overwriting the stack, then when the "return" portion of the return/call pair in the asm code that executes functions tries to get the return address from the stack, it has been overwritten and control is vectored to the new code sent to the stack, not the correct return address. An inability to execute code on the stack would stop buffer overflows from executing by crashing the program with some kind of protection fault, which would generally be preferable to being o3ned :)
Re:So simple, we might as well do it. (Score:3, Interesting)
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
Re:So simple, we might as well do it. (Score:5, Insightful)
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 [core-sdi.com]
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
Re:So simple, we might as well do it. (Score:4, Insightful)
Re:So simple, we might as well do it. (Score:3, Informative)
http://community.core-sdi.com/~juliano/exploit_tu
steveha
DRM? (Score:3, Interesting)
Re:DRM? (Score:5, Informative)
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).
Expect intel to make a counter to this... (Score:3, Insightful)
Re:Expect intel to make a counter to this... (Score:5, Informative)
Either way, it's nice to see everyone supporting this. Definatly seems like good technology to me.
Anti-virus? (Score:5, Insightful)
I just love tech journalism...
Re:Anti-virus? (Score:3, Interesting)
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.
Re:Anti-virus? (Score:2)
It won't help people who open a program they think let's them download free porn but is actually a virus, but it could help stop viruses t
Re:Anti-virus? (Score:2)
Unfortunately this means other, legitimate self-modifying code may also have issues
OpenBSD (Score:3, Informative)
It would seem like a logical (and swell) thing for Transmeta to do
OpenBSD W^X (Score:4, Interesting)
Re:OpenBSD W^X (Score:4, Informative)
Re:OpenBSD W^X is weaker (Score:2, Informative)
Let me guess... (Score:5, Funny)
compiled (Score:3, Insightful)
Re:compiled (Score:2, Informative)
Failure ? (Score:2, Interesting)
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
Re:Failure ? (Score:5, Insightful)
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 [avayalabs.com]).
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...
Re:Failure ? (Score:5, Informative)
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.Re:Failure ? (Score:3, Interesting)
The very fact that DRM "consumes valuable resources" and doesn't provide an IMMEDIATE payoff will, by definition, lead to the corporate worlds de-railment of it. The corporate world has a nasty habit of wanting PERFORMANCE AND PROTECTION while simultaneously subverting "valid" methods of attaining this goal (ie: Clean, Secure, and Safe code, etc). Most corporations want more, but aren't willing to pay for it. As
Does Transmeta have a future? (Score:4, Informative)
Sure. (Score:3, Informative)
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)...
why no NX on IA-32? (Score:2, Interesting)
Re:why no NX on IA-32? (Score:2, Informative)
There are some kernel patches such as grsecurity which do emulate this functionality in the kernel, but that brings performance down.
I don't understand (Score:4, Insightful)
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?
Re:I don't understand (Score:2)
I suppose (and this is 100% hypothetical) that there might be very rare situations where the programmer will need to be able to override, but so be it.
Re:I don't understand (Score:3, Interesting)
Haven't Intel processors had this for YEARS? (Score:3, Insightful)
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?
Re:Haven't Intel processors had this for YEARS? (Score:3, Informative)
NX - Nitrous Express?!?! (Score:3, Funny)
Transmeta hired Babayan's student instead of him.. (Score:5, Interesting)
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.
And we only had to wait 7 years (Score:2, Informative)
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-mod
Quick tutorial: code/data, buffer exploits, OS,MMU (Score:5, Interesting)
* Usage of a von Neumann architecture
* Storing call stack in buffer space
And it blossomed from there.
A von Neumann architecture [wikipedia.org] 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
Finally... (Score:3, Interesting)
Change the ISA encoding. Random ISA codings. (Score:4, Interesting)
Good luck creating a worm for a "custom" arch.
Hedley
XP SP2 adds NX support (Score:5, Informative)
http://www.microsoft.com/technet/prodtech
Linky (Score:4, Informative)
http://www.microsoft.com/technet/prodtechnol/winxp pro/maintain/sp2chngs.mspx [microsoft.com]
Re:Motherboards! Please! (Score:3, Insightful)
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 rea
Re:Scheme (Score:3, Interesting)
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.
So don (Score:3, Informative)
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