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."

Comments

Enterprise Computing?

[AKAImBatman]

If they call it the "NX-01", I'm gonna shoot somebody.

Re:Enterprise Computing?

[DarkHelmet]

NX-01? Is that a Star Trek reference? I always thought that Star Trek ended after First Contact. Damn... I'm glad they didn't drag that franchise out and run it into the ground...

Or maybe I'm from a parallel universe...

Re:Enterprise Computing?

[cbreaker]

Star Trek. It's the ship tag of the ship on the show Enterprise.

I didn't RTFA, but

[alphakappa]

can someone please explain why NX is important (and how it is differnt from NOP), and why it was not there earlier? Thanks

Re:I didn't RTFA, but

[zgornz]

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.

Re:I didn't RTFA, but

[bnavarro]

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

Re:I didn't RTFA, but

[Rosco P. Coltrane]

it is a hardware implementation to the "execute" flag in unix/linux. I guess Microsoft doesnt write good enough software to implement it on its own-unlike linux. NOP tells the processor to not do anything for a cycle.

Microsoft certainly knows about NOP though...

Re:I didn't RTFA, but

[tedu]

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.

Re:I didn't RTFA, but

[tedu]

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.

No Execute?

[Anonymous Coward]

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?

Note to editors

[Anonymous Coward]

The NX bit is not an 'antivirus' feature.

Re:Note to editors

[Just Some Guy]

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.

is this worth it?

[Sunda666]

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.

Re:is this worth it?

[LostCluster]

Because any time you're allocating memory for yourself, the OS isn't quite sure just what you're going to put there. When it's assembly-written code, the OS really can't tell the difference between the load of more code and the load of data.

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?

[MonMotha]

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.

Re:is this worth it?

[AKAImBatman]

It wouldn't be a problem if OSes properly separated code and data segments. By marking it properly in the GDT or LDT, even an exploit in the kernel shouldn't allow arbitrary code to run. And if the write does continue into a code segment, a general protection fault should occur.

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?

[Chester K]

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.

Re:is this worth it?

[e9th]

Unless it's a 'trusted' app. Find a hole in /usr/bin/su and you're home free.

Re:is this worth it?

[MonMotha]

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.

Re:is this worth it?

[AKAImBatman]

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.

Re:is this worth it?

[G-funk]

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.

I did RTFA

[magefile]

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?

Re:I did RTFA

[MBCook]

N o e X ecute.

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?

[AKAImBatman]

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.

Re:How is this different?

[RuneB]

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.

Re:How is this different?

[RuneB]

The x86 only has two bits per page, Readable and Writable. You can't mark a page of memory as readable without marking it as being executable, they are the same thing on the x86.

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.

Re:How is this different?

[YU Nicks NE Way]

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.

Re:How is this different?

[AKAImBatman]

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.

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 notes...

Re:How is this different?

[achurch]

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.

Re:How is this different?

[YU Nicks NE Way]

[I]sn't that a problem with the way that Windows executable are directly mapped to memory?

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 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.)

Re:How is this different?

[RuneB]

Right, this segment-level protection is what the various no-execute patches do for x86. It isn't as easy to use as it looks, though, and there can only be one code segment at a time.

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.

How well will this work against VBScript viruses?

[netsharc]

Because, VBScript viruses come as source-code, and the script engine reads it and executes the functions that the commands want.

Or .exe attachments, I bet they will still work when the hapless user double-clicks on them.

Or ActiveX holes.. well this would be harder to exploit with the NX feature..

So simple, we might as well do it.

[LostCluster]

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.

Re:So simple, we might as well do it.

[Monkelectric]

into an about-to-be-executed chunk memory.

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.

[csirac]

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.

Re:So simple, we might as well do it.

[steveha]

A buffer overrun is a way of putting data PAST the end of your variable (which would be marked NX in your hypothetical scenario) into an about-to-be-executed chunk memory.

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

Here's the text of a comment from the sample code:

filling up the end of the buffer with our shellcode which will be executed on the stack after the bof

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.

[YU Nicks NE Way]

There are such attacks, but they are extremely subtle. Basically, instead of jumping to their own code on the stack, they write a different overflow which patches in a call to exec(). (Unix only, but on a Windows box, ShellExec will do just as well.) Hey presto, direct shell.

Re:So simple, we might as well do it.

[steveha]

Here's an even better tutorial on how to do buffer overrun attacks:

http://community.core-sdi.com/~juliano/exploit_tut orial.txt

steveha

DRM?

[NETHED]

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.

Re:DRM?

[MonMotha]

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).

Expect intel to make a counter to this...

[User 956]

Just like Intel developed and implemented the Centrino spec which surrounds and supports the low-power Pentium M in order to compete in the wireless/ultraportable arena with products incorporating the Crusoe and the Efficieon, you can expect they'll have something up their sleeves with regards to this. I mean, it's not like they're just sittin' alone in their parents' basement watching Buffy reruns, and spanking it to naked Portman pictures.

Re:Expect intel to make a counter to this...

[MBCook]

This is a counter to AMD adding NX to the Opteron/Athlon64 line of chips. Intel already countered that by announcing that it would have NX on it's chips (which it calls NE or ND or something) a few days ago.

Either way, it's nice to see everyone supporting this. Definatly seems like good technology to me.

XP SP2 adds NX support

[Barlo_Mung_42]

I know you were attempting a joke. But to bring it back on topic:
http://www.microsoft.com/technet/prodtechn ol/winxp pro/maintain/sp2chngs.mspx

Anti-virus?

[__aagctu1952]

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...

Re:Anti-virus?

[26199]

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.

OpenBSD

[Anonymous Coward]

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

OpenBSD W^X

[mph]

Doesn't OpenBSD already provide this functionality, on existing i386 processors?

Re:OpenBSD W^X

[CTho9305]

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.

Let me guess...

[mikeophile]

The "no execute" function is a subset of a call from a governor.

compiled

[Stevyn]

doesn't this required the software to be rewritten to use it? I think it would make much more sense if NX were replaced with something in the os that didn't automatically allow software to be installed by clicking "OK" on some web page. Even though it's annoying to have to type in the root password constantly in Linux, it's a hell of a lot easier than reformatting and reinstalling as I've done for too many people. Even if the computer is operated by one user, this requirement of the root password still makes them more aware that something is about to modify their system. Those activeX dialog boxes in IE make it seem like gator is a new and exciting feature and that's why people install it so much.

Re:compiled

[getnate]

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

Failure ?

[polyp2000]

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 ...

Re:Failure ?

[bersl2]

"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...

Re:Failure ?

[hchaos]

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?

It's just you. The reality is that there is a tremendous failure on the part of the hardware vendors that would require this to be done in software.

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").

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?"

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 ?

[bergeron76]

The parent post is actually one of the most insightful posts that I've read on /. as of late.

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 a result, they have no choice but to assault our basic consumer rights (and civil liberties) via their lobbyists in Washington.

Your post hits the nail on the head - much like digital music, the GENIE is out of the bottle. DRM could fail because it will require a performance hit that the corporate world probably isn't willing to take.

Re:How well will this work against VBScript viruse

[LostCluster]

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.

Does Transmeta have a future?

[mst76]

It's common knowledge that their older Crusoe processors had rather unimpressive performance. They had a small niche in energy-efficient computing, but even there they didn't appear much better than the ULV Tualatin mobile-P3s to me. Recently I read some claims that their new Efficeon would perform almost on P-M levels. But the first real benchmarks I found tells a complete different story. From the conclusion:

Unfortunately, the efficeon is a staggering failure by nearly every measure.

Performance is unambiguously lackluster. In fact, efficeon is only slightly faster than Crusoe. If it weren't for the other Transmeta products and the 366MHz AMD Geode, thrown in for comic relief, the Crusoe would be dead last even when compared to the miniscule VIA C3.

Given this, is there any hope left for the company?

I don't understand

[gerardrj]

Granted, I haven't really paid much attention or done any research on this no-execute flag, but it seems to operate within the data structures of a program such that you can flag a structure, memory block or references to it as non-executable.

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

[gerardrj]

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?

Haven't Intel processors had this for YEARS?

[callipygian-showsyst]

IIRC, from the original '386 architechture forward, a segment can be marked as data or execute. For example, see this reference

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?

[getnate]

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

Linky

[M.C. Hampster]

http://www.microsoft.com/technet/prodtechnol/winxp pro/maintain/sp2chngs.mspx

ok, i see part of this...

[ecalkin]

nx is a flag on a page (or block) of memory that indicates to the processor that i shouldn't be executed (page address not loaded into the ip?)

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), except that code should be marked read-only anyway... i'm kinda iffy on this.

but how in the world is this going to do anything to prevent a viral attack?

eric

Data General & the obscure Motorola 88000-seri

[mosel-saar-ruwer]

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.

NX - Nitrous Express?!?!

[sickmtbnutcase]

Man, these chips are gonna fly...till the bottle runs empty. Oh, wait, I should go read first.

Re:why no NX on IA-32?

[DA-MAN]

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.

Re:OpenBSD W^X is weaker

[Anonymous Coward]

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.

Transmeta hired Babayan's student instead of him..

[hansreiser]

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.

Sure.

[pb]

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)...

And we only had to wait 7 years

[Anonymous Coward]

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

Re:Data General & the obscure Motorola 88000-s

[nacturation]

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.

Quick tutorial: code/data, buffer exploits, OS,MMU

[stienman]

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

Re:Motherboards! Please!

[steveha]

Duh, build an Althon64 system.

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 really love my tiny, quiet little Mini-ITX servers with VIA C3 chips. Great for email servers, file servers, etc.

Not every computer needs to run Doom III.
steveha

Finally...

[rdean400]

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.

Re:mod parent down

[Too Much Noise]

Actually, it's per page, not per segment. Segments had an exec flag from 32bit day one and this was the card Intel hoped people would play[*]; they were mostly wrong though, the segment-level protection did not get used so much.

[*] 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.

Change the ISA encoding. Random ISA codings.

[hedley]

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

Re:Scheme

[cbiffle]

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.

Re:Scheme

[Anonymous Coward]

Scheme uses byte-code, so it has nothing with processor. And, after all, it's safe agains buffer overlows :)

Vadim

So don

[ZigMonty]

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.

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.