Slashdot Mirror
Transmeta To Add 'NX' Antivirus Feature To Chips
Autoversicherung writes points to a ZDNet story which says that "Transmeta will support "No Execute," or NX, in their next core revision.
Transmeta will provide advance versions of Efficeon-based systems with NX support to Microsoft for testing. Hope Linus get a few too, even if he's no longer working there.
The NX-equipped Efficeon chips are due for general release later this year."
If they call it the "NX-01", I'm gonna shoot somebody.
Javascript + Nintendo DSi = DSiCade
can someone please explain why NX is important (and how it is differnt from NOP), and why it was not there earlier? Thanks
"When the only tool you own is a hammer, every problem begins to resemble a nail." - Abraham Maslow (1908-1970)
While security is good the problem with these chips is less than obvious. Needing to get around these security chips will force many hackers to work on ways to hack things such as these, providing a wider base of security bypassing techniques. A better idea is to use something like bind (not to be confused with the BIND of DNS) that uses pseudo-randomization to keep hackers out
just limit the buffers? So they can't overflow.
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?
...Windows running on these
you may find the Higgs in this signature.
The NX bit is not an 'antivirus' feature.
Hmm I may be totally wrong here, but ain't this NO EXECUTE thing a responsibility of the operating system?!?
Why implement this at the hardware level, besides "making windows more secure"?
cheers.
``If a program can't rewrite its own code, what good is it?'' - Mel
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?
Ok, maybe I don't get this. How is this different from marking a block of memory as data, not code? The real problem is that certain OSes mark all memory as both code and data. Sure, it's easier on the bookkeeping, but it allows buffer overflows. If data was kept in data segments, and code was kept in code segment, the worst that would happen is a corrupted data segment, and/or a General Protection Fault.
Javascript + Nintendo DSi = DSiCade
Because, VBScript viruses come as source-code, and the script engine reads it and executes the functions that the commands want.
.exe attachments, I bet they will still work when the hapless user double-clicks on them.
Or
Or ActiveX holes.. well this would be harder to exploit with the NX feature..
What time is it/will be over there? Check with my iPhone app!
Isn't that a feature of windows? As in when it issues a no execute when you try to run an executable then BSODs.
Call me crazy but who wants microsoft software to have anymore to do with their bios..Watch, within a month or two "a virus protection feature" will become an antipiracy/linux feature..
Not to mention the linux people will have to start on a new bluescreen screensaver...
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.
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.
--sig fault--
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.
The theory of relativity doesn't work right in Arkansas.
I know you were attempting a joke. But to bring it back on topic:n ol/winxp pro/maintain/sp2chngs.mspx
http://www.microsoft.com/technet/prodtech
How exactly is this an anti-virus feature? Anti-buffer-overflow, yes. Anti-worm... well, maybe, but it'd be a bit of a stretch (anti-worm-based-on-buffer-overflow rather). Anti-virus? Hell no.
I just love tech journalism...
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
Doesn't OpenBSD already provide this functionality, on existing i386 processors?
Or .exe attachments, I bet they will still work when the hapless user double-clicks on them.
Short answer, it won't.
The "no execute" function is a subset of a call from a governor.
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.
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
Electronic Music Made Using Linux http://soundcloud.com/polyp
Malicious VBScript and unsafe .exe files are pretty easy to avoid in the first place though. Where this would come in handy is for things like maliciously crafted data files that exploit buffer overruns in software, and service exploits like the ones used by Sasser and other internet worms..
Oh come on, why did you say that? You act like you know what you are talking about, but clearly don't. This is all about buffer overflows, not viruses. Sure, the editors don't have a clue either, but thats no excuse.
If you don't know what an article is about, just don't post. And to the people who moderated this up, shame on you!
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.
Why hasnt intel or AMD added NX to IA-32?
You don't get the three rwx bits on x86. You only
get three states:
1. rwx
2. r-x
3. ---
That's it. With the NX feature, you also get:
4. rw-
5. r--
The OS is stuck mapping your desired permission
bits to what the hardware offers.
Self-modifying code causes trouble when you
enable the NX feature for old binaries. There
are ways to work around this, by marking your
executables as NX-compatible or not.
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?
Article X: The powers not delegated... by the Constitution...are reserved...to the people
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?
Best Buy can have you arrested
http://www.microsoft.com/technet/prodtechnol/winxp pro/maintain/sp2chngs.mspx
Forget the whales - save the babies.
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
OpenBSD is taking advantage of an old x86 feature.
On the i386, you can place an upper limit on the
memory addresses that are executable. You can't
pick and choose which parts of memory are executable
with this; all you can do is divide memory into
two parts and get no-execute on one of those parts.
OpenBSD can try to place pages of code low and all
other pages high, in order to maximize the amount
of memory with no-execute protection. The protection
gets lost if you simply mark just one high-address
page executable. With NX, you can keep protection
on all the other pages.
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.
Man, these chips are gonna fly...till the bottle runs empty. Oh, wait, I should go read first.
Transmeta has cured the common cold? I believe a Nobel Prize is in order!
True story.
why do people get to have such long urls for their homepage with no space to break it up. page wideners suck.
> 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.
Linus works at Microsoft? Since when?
NX is not an instruction, it's a flag. Think in terms of the Evil Bit. A boolean value saying "No, this bit of data is not executable".
Has nothing at all to do with instructions, except that you can't execute instructions in a data segment with the NX bit set.
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.
If you remember the Efficeon is basically a 254bit CPU emulating an amd64 4x/clock (the older transmeta - crusoe - used to be a 128bit chip emulating a p6 4x/clock. It also will have the same built in memory controller, and will use nvidia nforce3 chipsets (that will bring the long awaited agp support to transmeta cpus).
This is not new news, old since it has been released that the new transmeta will emulate the amd64, and have memory controller on die, as well be pinn compatible with amd64 so it is kind of expected to do the other tricks as well...
If its as good as most BIOS's its trash.
Duh, build an Althon64 system. Althon64 and Opteron already support NX. MicroATX boards are available... As Nike once told me, Just Do It.
This would certainly be a much better system than the crappy Efficeon could ever hope to be. All of Transmeta's stuff has had lackluster performance (worse than VIA's crap).
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
Just goes to show that technological leadership is never any guarantee of marketplace leadership - x86 hardware is only now getting some of the features that Data General and Motorola were peddling [without much success] about fifteen years ago.
Completely unrelated to this is the fact that patents last only seventeen years. I'm sure it's a coincidence though.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
From what I've heard, only Windows uses this 'anti-virus' feature. What do you think the chances are that it's just yet more M$ DRM being snuck in at the hardware layer under the pretence of increased security?
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
This wouldn't work w/ a language like scheme. Procedures are frequently created and/or modified at runtime.
if you get an overflow on nx page, and the system response is to kill that process, what does that mean for your application? does this mean you should be writing seperate processes for any potentially vulnerable parts of the application so the whole thing doesn't crash? what about in a server situation and your app gets showered with the exploits, dumping all your processes before they can do anything useful?
if the overflow on the nx page DOESN'T kill the process then you need to have some exception code to get the process back to a useable state, which is sizeable itself, if a bunch of processes are doing this all at once...
and how about single process applications? does this mean you can't use non-blocking io any more becasue one exploit will bring it down?
ok, so it is failfast, which can prevent some one running malicious code, but it doesn't give you instant perfect code.
problem: our software is flawed
solution: throw some hardware at it
Viruses require a process host, vbscripts, exe, etc.. run in their own process. They are trojans as they pretend to be something else to entice people to execute them. I don't know why it's so hard for people to get the terminology correct.
I suppose (and this is 100% hypothetical) that there might be very rare situations where the programmer will need to be able to override
Have you run a Java applet in the last week? If so, you've needed to override it. Just-in-time recompilers such as those for the Java and .NET platforms use self-modifying code by necessity.
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
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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.
Underclock the Athlon, run a huge heatsink, run a quiet fan at a low voltage. Almost no sound; certainly much quieter than any hard-drive I've been able to find (Seagate Barracuda being the quietest).
A completely passive system doesn't buy you anything if you run a hard-drive.
The Dept of Interior got a deal of some sort on those around '90 and they could buy them like candy. They were good, solid machines. A lot of the standard Unix programs on them were actually from the GNU project.
the good ground has been paved over by suicidal maniacs
Code segments are already read-only (unless you're doing self-modifying code, which is a separate issue entirely). The problem is that data segments, which must be writable for obvious reasons, can't be marked non-executable. At least, I don't see anything in the document you linked to saying code in data segments can't be executed, and I suspect if it was possible to prevent execution then someone would have done it long ago.
Incidentally, at least some common compilers (GCC, for instance--I just checked) scatter constants throughout the code segment, so there's no such thing as a "constants pool". You need read access to the code segment, period.
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.
Which is very similar to how the US phone system used to work. Originally, calls were routed using "in-band" information. Basically, a series of tones that the switches would spit onto the voice circuit to tell the next switch down the line the who/what/where to send the call.
Needless to say, easily exploited by the phone phreakers of the day.
So the phone system was redesigned to put all control communications "out-of-band", making phreaking not possible because the voice circuit was no longer listened to for control signals.
Fast-forward 30 years and we find that the computer folks weren't paying attention to that particular lesson.
Wow -- that was my first post ever to be modded down to -1. And I wasn't even trying!
That will sure teach me to talk about Efficeon motherboards when the topic is Efficeon chips. I have learned my lesson. I am a changed man.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Load in a gigabyte of RAM, and set up a network boot from one of my VIA C3 servers. No hard drive. It would work just fine for email and web browsing, and playing tunes and DVDs.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
NOPs take up time and space.
Used to fill address space or occupy processor time until an interrupt.
This in important to timing issues and content of nonexistant memory issues (the interpretation of all ones or all zeros plays a part in the second issue.)
A NOP that literally did nothing - was skipped - would be useless as an assembly instruction.
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
I'm sure the OpenBSD people are going to like this chip.
These two decisions provide great flexibility and power in memory management, but with great power comes great responsability.
Using in-band dial tones doesn't have any advantage aside from simplicity. Von Neumann architecture is as simple/complex as any other, it's the side effects we are interested in... So why should we follow suit?
From what I read here, this seems likely to be a good security feature. But tell me, what would happen if a cracker/virus/otherBadStuff were to exploit a bug and set NX on a part of the kernel. Something to watch for.
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
And as long as I'm dreaming, I'd love a 2-way or 4-way Efficeon SMP motherboard. It would always be snappy and responsive, would have plenty of power for my day-to-day tasks, and could still be really quiet or (I hope) totally silent.
You've just described my dream workstation! I wish it made economic sense to produce a product like that...
If they made a movie of your life, would anybody buy a ticket?
Also worth noting is that 68k Motorola MMUs - 68851, 68030+ internal - can have separate address- and codespace. It's completely possible to configure them so that stack (used for local variables) behaves normally when used for it's intended purpose, but causes exception when someone tries to execute it as code.
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.
OK, so now you will have that every buffer overflow problem that a virus could exploit to insert custom machien code will be stopped before it can happen.
Instead, whenever a buffer overflow exploit is attempted, the regular process/thread/control flow will be interrupted to "protect" the data area from running the code. In essence, the OS in collaboration with hardware will deny the process an opportunity to execute further, thus transforming every "code insertion through buffer overflow" into a "denial of service" attack.
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.
go Harvard go! Take that, von Neumann!
Free as in mason.
I have seen some software implementations of this available as kernel patches, but I haven't seen it in the linux kernel.
OpenBSD supports it on systems that support NX.
Solaris should, but I cannot guarentee it.
XPSP2 does, but not on intel chips.
The stack is where buffer overflows occur, and you don't run code from the stack normally. So the OS just marks the entire stack no execute and that is your protection.
It works very well, but of course it isn't quite foolproof.
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.
Umm... denial of service is *much* better than executing malicious code. No, it won't stop buffer overflows. If the code is broken, there's no easy way to fix it in hardware. At least this thing will kill the process before you get 0wn3d.
Great comment, just a little nitpick:
;-)
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 is not _entirely_ true actually. Technically, since you usually know the software that's being exploited, you could find a piece of code (anywhere in the code segment) that you could 'abuse'.
In other words, with NX, you can still return to an arbitrary point in the code segment. So you find a piece of code that when called (possibly using a different than intended context) provides functionality you desire. Voila. It may proof very hard to find 'usable' code, I'm sure the NX feature will bring that to light soon enough (or hopefully not).
One solution to this is dynamic code relocation. In other words, shuffle code around within the code segment so that a malicous coder can't guess the location of a piece of code (s)he could potentially use.
The BEST solution is to have a seperate call and data stack. The call stack could in theory be entirely read/write protected from the process. Of course this is a feature of the CPU and the x86 just doesn't have that feature. Well, that's not entirely true either, the x86 does allow you to have a seperate call and data stack. You couldn't write protect the call stack, but you could make it so buffer overflows can't access the call stack. This could actually be implemented by a compiler change, I think. Gotta think about that some more...
However, with all this, it would STILL allow for people to manipulate the behaviour of the program by adjusting variables (through buffer overruns).
Bottom line though, combine all possible solutions (NX support, use buffer overflow checking libraries in C(++) programs at least durring development, use a language that protects against buffer overflows in cases where it makes sense, etc...) and you have made it a LOT harder to compromise a system.
Then again, it indeed won't protect against people running an executable inside a ZIP which arrives as an attachement from a stranger...
From the article:
The NX technology is a Internet standards based technology solution that enables the complete elimination of any malicious code sent via network communications. By leveraging RFC 3514, Transmeta's NX technology identifies any packet flagged with an "evil bit" and refuses to execute it.
I've been waiting for this.
This thing is snake oil. No, really. Every penny being spent on it is a penny wasted.
The ultimate example of built-in "No eXecute" would be a Harvard architecture machine (e.g. PIC series), where the executable instructions and non-executable data are placed in electrically separate memory.
But such a machine can still make a decision based upon the contents of a non-executable memory location -- otherwise a Harvard architecture machine would never be able to emulate a Neumann architecture machine (ever played old ZX Spectrum games on a mobile telephone?) And the consequences of that decision might affect the contents of executable memory locations, otherwise you could never load any software into executable memory.
You can effectively disable the NX functionality by running a little "emulator" to read non-executable memory and treat its contents as instructions. If you were really, really evil, you'd just set it as the default exception handler for attempted execution of NX'ed code and forget the rest. Getting the emulator into place in the first place is just a matter of persuading a clueless user to let you do it {e.g. by disguising it as a kewl new game, or pr0n, or a utility to block adverts / fill in passwords / do single-click web searches / download free music files / share your contact information with friends, &c}. My inbox is a testament to the fact that some people will click on anything.
Furthermore, once a "hardware solution" is in place, programmers will invariably get sloppy, assuming it will actually work, expecting it to do their job for them, &c.
Je fume. Tu fumes. Nous fûmes!
I been writing self-mod'ing code for almost two decades and yes it is sometimes user controled thru a process diagramming interface, but mainly it is self-optimizing code. I understand the need for NX but sure wish it was a tri-state flag.
But what's the point of having an NX capable machine? You aren't really using that machine for anything other than an appliance. Which is fine, but having the NX stuff isn't necessary for that.
We're talking NX systems here.
NX is a great idea for compiled binary code. It doesn't help with interpreted code, though. The interpreter runs in eXecutable memory, the code it interpretes can be in NX memory. Some examples of interpreted code are: Java bytecode, DOT NET MSIL code, any interpreted languages like Perl, TCL, Python, Ruby.
- For the complete works of Shakespeare: cat
That's a good point. However, I don't see anything saying that executable memory (ie. not marked NX) is not writable. So, you can't execute data, but you can write data to executable memory. Is this right?
/earth is 98% full. move everyone you can to /luna or /mars
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I think the NX is a good idea, and I'd like it on all my computers. But the specific reason I want Efficeon chips is so they can run with just a heatsink, for the quietness.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
What CPU/OS combination do you use?
If the application is not available, there no business is done. If no business is done, no money is made (="no value is created", whichever way you prefer). If no money is made, I die of starvation or switch to caveman-style living, picking berries in the woods.
It's a good step, at least you don't get 'owned', but the hype is created and the propaganda that is being spread around deceitfully suggests that NX is a magic bullet...
Yes, that's right. Anything that doesn't have the NX flag set works just like memory does today on a system wher the NX flag doesn't exist. Having the flag off doesn't make the memory special "executable memory" that isn't allowed to contain data, it just means that the no-execute restriction doesn't apply.
I'd rather be lucky than good.
Mainly WinTel32 now (no flames please), but of course Linux also. Started doing limited stufff on a PDP8, then a Vic20, but the C=64 was the the most fun (graphic routines mainly on that, anyone that knows both 'published' games gets a NOS copy of them!). But been there on 'old style' HPUX and IRIX (my favorite). Its a pain in the ass anymore and is easier to license and include a compiler, do 'on the fly' code generation, C,L,L the new library and drop the old one (This is the only practical way for WinTel64).
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
And you wonder why you got an offtopic moderation?!
This is Slashdot. All sorts of somewhat-related topics get posts, and often get moderated up. For example, on a discussion of privacy issues in the wilderness, a side thread about joining a search & rescue team wasn't exactly on-topic, but was moderated up rather than down.
As another example, your comment isn't about NX either, but you felt free to make it. And I doubt a moderator would be sufficiently offended by it to moderate it off-topic, even if any moderators were paying attention to this topic anymore.
If Slashdot was intended to be narrowly moderated, there would be more topics, and there probably wouldn't be a "funny" moderation (because jokes are really pretty off-topic most of the time).
I wouldn't have been surprised much to be moderated down, but I was surprised to be moderated all the way down to -1. And I guess I failed, but I was trying to be funny in a sort of sarcastic way. (Tip for any moderators reading this: if you want to go back and mod down my attempt at humor, I sugget you use "overrated" since there isn't a "not funny".)
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
New here, huh? Buy that account on Ebay? OK, I get it...
-1, Overrated.
lf(1): it's like ls(1) but sorts filenames by extension, tersely