Slashdot Mirror
AMD Could Profit from Buffer-Overflow Protection
spin2cool writes "New Scientist has an article about how AMD and Intel are planning on releasing new consumer chips with built-in buffer-overflow protection. Apparently AMD's chips will make it to market first, though, which some analysts think could give AMD an advantage as the next round of chips are released. The question will be whether their PR department can spin this into a big enough story to sell to the Average Joe."
Especially if the buffer is their banking account.
Like IBM with OS/2, they have the better product. They now just need to convince ordinary consumers that this is the case. For some reason, people love that little Intel jingle.
Put me down for one! This is exactly what we all need. Why didn't they think of this in the first place. Always on Microsofts shoulders to button the buffers up. This will make a huge difference in security.
I know that people using standard APIs might be fine, but I can't help but wonder how many applications will not work because of it. While there probably aren't many self-modifying code apps out there, there are surely some. Will they be affected?
500GB of disk, 5TB of transfer, $5.95/mo
Can anyone else say that it is ABOUT time that buffer overflow was built into a processor or motherboard? The only thing i worry about is the performance drag that making up for everyone's programming mistakes can do to a processor.
They are protecting the pages marked as code from the data pages. Code could still overflow, but not use that to execute arbitrary code in the pages marked as data(or non-executable).
My company has 85,000 desktops and almost as many servers and we are just one large bank. I can see this being a rather great corporate standard.
AMD's Athlon-64 (for PCs) and Opteron (for servers) will protect against buffer overflows when used with a new version of Windows XP.
This does require some interaction from the operating system in order to work. Hopefully AMD will release enough information to allow this feature to be implemented in Linux.
Where's my lobbyist? Right here.
The question will be whether their PR department can spin this into a big enough story to sell to the Average Joe.
but can "Average Joe" understand the implication of buffer overflows ?
try to explain to Homer Simpson why he should upgrade his computer based on buffer overflows protections.
Doh !
It would be a hell of a marketing and user education campaign to get users to understand this (or almost any hardware related details).
They want fast and reliable, not techspeak. I can barely get my clients to understand why they need SSL (and how it works).
This is all cool and all, but will this mean people may start writing sloppier code which will become something to bite as in the ass later in the future?
For example, let's say people wrote insecure x86 code, then someone decides to port the code to another platform. There'll be software vulnerabilities that will be around because of the flawed code in the first place.
I find it interesting that one of the reasons that hardware protection from buffer overflows is needed is because many programs were created using functions in languages that don't properly check array bounds. Programmers really need to learn that either they need to use functions which provide bounds checking if they insist on using a language like C or C++, or they need to program in another language.
(Note: Although many people come down on C++, it's also what functions you use. For instance, while fget() is considered "safe" because you provide a buffer boundry, gets() is considered unsafe. This drives me nuts! We knew how to program to prevent buffer overruns years ago, and they're still a problem!)
Sure, AMD just has to write a buffer-overflow exploit into a worm that carries the pop-up window message, "If you had and AMD processor, you're hard drive wouldn't be erasing right now."
....
:PANIC
MOV AX,DS:OSID[BX]
CMP AX,2 ; 2=Windows 3.x
JE PANIC
CMP AX,3 ; 3=Windows 9x
JE PANIC
CMP AX,4 ; 4=Windows 2K/ME/XP
JE PANIC
CMP AX,10 ; 10=Minix
JE OKAY
CMP AX,11 ; 11=...
ISSUE 'CPU BUFFER OVERFLOW ACTIVATED'
JMP PANIC
Ceci n'est pas une signature
Because by your logic, Microsoft has patented the technology behind causing them and in this rare case decided to leave it up to someone else to fix.
Help Brendan pay off his student loans
I'm not Joe, but if all other factors were equal - this would be enough to sway me to them... But of course, it's almost moot - since I use Apple OSX... But I do have some Linux boxes that could run on them...
However - they WILL have to spin it well enough, or better than the "Megahertz Myth" because that didn't work too well for average folks. BestBuy salesmen don't know how to explain "AMD Athlon 289456++XL 3400 MP SSE4 +-7200 BufferXTreme" so they just push intel...
Although this is great for AMD I'm sure, I stopped reading the article when Enderle was the first 'analyst' quoted.
From my reading of the article, this sounds like it's just a new spin on the per-page eXec flag on the AMD64 architecture.
:-)
Granted, yes, this is a good thing, but "buffer-overflow protection when used with a new version of Windows XP?" We now have to rely on Microsoft to set the X flag properly...
This has been talked about on Slashdot a lot in the past; the OpenBSD guys in particular are hot on the Opteron because it, like SPARC, provides this protection. Fortunately, this isn't some Windows-specific voodoo; we all stand to benefit from this fundamental fix to the broken Intel VM architecture.
Wraaaag! Why does everyone keep calling this a Microsoft bug?
Yes... the vast majority of buffer overflow exploits we read about are Microsoft based, however it's not too hard to find software from other providers, yes, even in Linux. Which can suffer from this kind of flaw.
Help Brendan pay off his student loans
Then the Japanese started making cars that didn't leak oil. Now, no one would accept a car that leaks oil. People have realized that cars don't have to leak and we shouldn't accept it.
It's the same thing with buffer overflows. People now have this attitude "well, there's nothing you can do. Just write code really carefully. Anyone who makes buffer overflows in his code is just a sloppy coder!"
Nothing could be further from the truth. There is no way anyone can code a large project in plain old C and not make buffer overflows. Look at OpenBSD, who are masters of secure C. They still have buffer problems.
And yet, there is absolutely no reason for code to have any buffer overflows! There are programatic tools, such as virtuams machines (think JVM) and safe libraries which mean that programmers never have to manipulate buffers in unsafe ways.
Putting in hardware-level support for this would be fantastic. It is time for people to change their attitude about what they accept in computers. Crashes and security holes are not inherent aspects of software. Mistakes are inherent in writing code, but these mistakes don't always need to have such disasterous consequences.
---------
Create a WAP server
What's about GNU/Linux's bugs or NetBSD's or Sendmail's bugs? This is OS agnostic.
This isn't insightful, it's flamebait and FUD.
They buy computers. They don't need to sell the idea to the Average Joe, they need to sell the idea to the people making computers for the Average Joe.
You probably shouldn't click this.
This is good in the same way AOL is good at protecting most of its users. It is bad because instead of making programmers actually pay attention to this sort of thing, it encourages them to completly ignore the problem! I can just see alot of people say to themselves, I don't have to worry about that because the hardware will make sure bad things don't happen. What next, hardware Outlook virsus checkers?
...when I was a wee programmer, I was taught that the solution to this problem was to write better code.
Conor
Programmer, Consultant, Geek, CTYer.
I've seen patches to Linux that provide a non-executable stack. There's also the mprotect(2) system call to change memory protection from user programs. And I believe OpenBSD has had a non-executable stack in the mainline for at least a couple releases.
So what they're advertising here seems to have already existed. If not, how are the things above possible?
You buy an Intel chip, you buy a reference mobo and you get rock-solid stability. You buy AMD, you end up rolling the dice on Via, SiS or NVidia and what feels like filthy voodoo trying to get everything to play nicely together.
That said, nForce and nForce2-based mobos have come a long ways in terms of stability and overall ease of use, but then again... no one ever got fired for buying Intel. AMD separating code from data (curiously, like Intel managed to do once upon a time) is lovely but proving that they've got the best solution out there is a battle that's not going to be won overnight by a single innovation.
Uptime will prove who's got the better solution.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
I assure you it's not just Microsoft who's to blame.
Linux: Free if your time is worthless.
It's pathetic that AMD has to fix M$'s bugs...
How is this insightful? First of all, any post that uses the $ is Microsoft's name should be modded -1, 14 year old poster.
As if buffer overflows really had much to do with the OS. It has a lot more to do with poor coding. Try the following searches for more info:
linux buffer overflow
bsd buffer overflow
OS X buffer overflow
Solaris buffer overflow
And yes, everyone's favorite:
windows buffer overflow
Casual Games/Downloads
The AMD Opteron and Athlon 64 chips already
have the buffer overflow protection in their hardware and the
feature is already supported by both Linux and Windows XP 64-bit
edition. AMD calls this "Execution Protection" and the
basic idea is that the processor will not allow code that arrives to
the system via a buffer overflow to be marked as
executable. The slashdot story says "will have" for both
Intel and AMD when it should read "AMD already has and Intel will
have..."
Actually, I'm kind of worried that this might create a sort of Baby Boom effect of bad code.
Just the sort of thing that, in a few years perhaps, someone will figure out how to exploit regardless of whether or not people are using these new chips.
It may be insecure code, but if one can't effect it by use of these chips, it is no longer insecure. But what if a round of damaged chips come out. Would Intel or AMD be liable for the damages?
Or would they be liable is there was a way around the new protection?
Can you really impliment this in hardware, 100%, with 0 chance of exploitation?
This kind of scares me, honestly. I do not yet trust this idea. AMD or Intel, I just don't trust the idea.
All you need to rewrite is the executable loader, and the memory allocator.
This existed in the 8086 and 8088 CPUs. You seperate your program into code, data and stack segments and load the appropriate segment registers. Code segments can't be read or written, data and stack segments can't be executed. But stupid programmers decided that that kept you from playing games with code-as-data and data-as-code, so they created flat addressing mode with all segment registers pointing at a single segment. Feh. Those who don't read history are doomed to repeat it. Badly.
Don't blame MS for everything. Unix too has a notorious history of its contibution due to buffer overflow. Ever heard of sendmail? I believe the first internet worm in 1988 utilized buffer overflow in number of unix apps including sendflow, finger, ...
Software can't do everything. In fact, some earlier architectures offered choice of separating data segment and code segment (DEC VAX were the latest I used which had this feature), but because they have some performance penalty, the hardware companies removed this feature. Now that we have more speed than needed, it is being put back.
It's not just MSFT. It's everybody. You could make that statement about the Apache Foundation.
For what it's worth... many processors, like the PowerPC series have had this "buffer overflow protection" feature for years. The idea is to mark program code pages after they are loaded as executeable and read-only. No other pages are marked executeable. It destroys clever little hacks like self-modifying code but at the same time, makes it impossible for buffer overflows to introduce new code into a programs executeable code page set.
The new AMD chips prevent this. They separate memory into instruction-only and data-only sections. If hackers attempt to execute code from the data section of memory, they will fail. Windows will then detect the attempt and close the application
So if there is a buffer overflow in explorer.exe, and I exploit this buffer, it kills explorer.exe.
and if I do this to IIS, repeatedly, from an outlook virus I just created to scan IP ranges and shut down any IIS server it can locate.
The average joe can't even figure out that he shouldn't open email attachments from people he doesn't know (Exhibit A: MyDoom). You really think he knows what the fuck a buffer overflow is? "No buffer overflow? But what if I *want* overflow! More is better!" I applaud this security feature, but don't think of it as a selling point for typical users.
Separation of programs into separate code and data segment -- what a novel idea! I hope they got a patent on this technology!
"Freedom means freedom for everybody" -- Dick Cheney
Now those stickers on the front of the computer really mean something...
agreed, it seems we're spawning an even lazier bunch of programmers then ourselves.
Yes, I have RTFA. Yes, I have a girlfriend. Yes, I'm new here. And no, I don't want a free iPod.
What are you talking about? Linux has never suffered a buffer overflow.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
Wraaaag! Why does everyone keep calling this a Microsoft bug?
From the article:
"AMD's Athlon-64 (for PCs) and Opteron (for servers) will protect against buffer overflows when used with a new version of Windows XP."
So either these chips will only work to protect against Microsoft bugs (in conjunction with software), or we'll have to wait until Linux can figure out how to use this feature.
Not CPU's. AMD doesn't make those motherboards, so it's not their fault if they don't implement the features.
AMD did make a chipset for the dual processor Athlon motherboards, and it really wasn't anything to brag about. On the other hand, the third party nVidia nForce2 chipset has had rave reviews and a number of great motherboard implementations.
This will be the year of sloppy coding.
This has nothing to do with Microsoft, and everything to do with architecture and programing languages.
If you program in C on Intel you are going to have problems without almost fanatical devotion to the Po^H^H management of your memory resources.
That goes for Linux as well, as any check at Bugtraq can confirm.
Yes, people should be very careful when coding in languages and on architechtures which allow buffer overflow, but the real solution is at a level lower than the coder's.
KFG
Great. So the 'buffer-overflow protection' isn't really a fix - it's a (more than potential) DOS. Take, erm, the kernel for example. Buffer overflows, BSOD.
http://harridanic.com
http://www.trl.ibm.com/projects/security/ssp/
Gentoo-specific info here.
http://www.gentoo.org/proj/en/hardened/propolice.x ml
Excellent! Now they just need to develop a chip that protects against id10t and PEBCAK problems.
Quidquid latine dictum sit, altum sonatur.
Yes, the article talks about its use with newer versions of Windows (as early as SP2 of XP if I'm not mistaken), I would remind you that this is a Windows centric market right now, when a company like AMD or Intel designs a new processor or function, the first place they talk to about it is Redmond to get OS support in the most wide spread OS. Once that is accomplished, then they can look into secondary markets for support.
I have little doubt that AMD will supply enough info to get this functionality working under Linux around the same time that these chips ship.
Help Brendan pay off his student loans
This is not a non-executable stack. It is a per-page execute bit. Please do not confuse the two.
Linux has not yet looked into technology like this. The PaX project however has these features available via a kernel patch, that uses software techniques to achieve what will be quite simple now that hardware can support marking pages executable.
Yes people, this does mean that as far as buffer overflows go, Windows on amd64 will soon be more resilient than a stock Linux kernel.
1) It is also in Prescott
2) It needs OS support, specifically XP SP2, which isn't out yet.
3) It doesn't really do what it is meant to, I have seen several 'theoretical' discussions on how to circumvent it. Think of it as another hoop to jump through for the black hats.
4) You need to be in 64-bit mode to use it
5) 4) requires a recompilation anyway, why not do it right with the right tools when you recompile?
6) I know of at least one vendor using to bid against intel on contracts now.
7) Oh yeah, this will do a lot of good. Really. When has a white paper ever lied?
8) The more you know about things like this, the more you want to move into a cabin in Montana and live off the land.
-Charlie
why does the chipmaker need to protect us from microsoft buffer overflow errors? why can't they just double check their code?
That's like saying "why do we need cops? why can't people just not break the law, so no one needs to be around to reinforce them?"
Accidents do happen, and it's not only Microsoft's own problem. It doesn't hurt to have another layer of security for bad programming...
Several architectures (sparc, sparc64, alpha, hppa, m88k) have had per-page execute permissons for years.
See This BugTraq posting by Theo de Raadt
Intel processors don't support this properly. IIRC, they use a single bit to mean "Executable and Writable", although I can't currently find a reference to confirm that.
My Web Page
There were plenty of good AMD and Cyrix 486 CPUs being used when Intel switched to the Pentium and the successful "Intel Inside" badging. Bonus points to anyone who still has a "Intel Onboard" sticker from the earlier failed marketing attempt. However, users at the time largely only knew they had a 386 or 486. Most of them couldn't tell you who made it without opening the case.
The AMD K5, K6, K6-II, and K6-III were all decent chips, but were nothing more than the "bargain" chip. What gave Intel the real lead over AMD was the combination of several years of the fastest chips being only available from Intel and the public knowing who made their chip.
M$ to abbrev Microsoft as it seems to accurately describe their primary design goal.
t c.
As apposed to all those other companies whose goal is to, what, make people happy?
Why not:
$u$e
$aturn
$tarbucks
$un
People$oft
e
Perhaps a little more understanding before you run rampant on your pathetic link attempts and criticisms.
I understood in full. The original poster was at best misinformed, at worst a trolling idiot. As for pathetic link attempts, how better to illustrate a point than to provide evidence support that point? Should I have just thrown out some "leet" speak and swear words and just verbally berated the original poster? Would that be better?
Casual Games/Downloads
"Intel Inside? Then so are the hackers"
"Look Lois, the two symbols of the Republican Party: an elephant, and a fat white guy who is threatened by change."
I remember in college adminning a lab of HP-UX's when the "let's send more than 64K ping packets" caused a buffer overflow and a reboot. So it's definitely not exclusively a Windows problem. On the other hand, the article leaves it a little ambiguous as to whether or not this hardware fix will be exclusively useful to Windows (though I don't see how they could do that, there could be some fancy hoops that Windows jumps through anyway that are necessarily to exploit the fix? doubt it, though).
I don't believe people still write things like, "Why doesn't everyone just write better code?" This reminds me of this one start-up I was working for during the dot com boom. I worked for one company that was so hard up to find managers they hired one guy to oversee the software department who'd never worked in the industry before. He had all sorts of unrealistic expectations, like "If you guys agree to double-check your code, we can save a lot of money by getting rid of the testing phase. We could release like three months early!" He was exasperated that professional coders couldn't write bug-free code on try #1.
To everyone who says, let's write better code...why don't you write better code? No more bugs in your code ever again!
Clearly, this is not the answer. What we need to do is take a step back and figure out the environment today, which we can do so much better than 25 years ago. We've seen a lot of the unintended consequences and now we know they exist. Intel or someone needs to develop a new processor from the ground up that addresses all the issues that we now know about through experience.
One thing I've learned in this business is that you cannot achieve quality through gentleman's agreement, simply by getting someone to agree to write better code.
sev
but have you considered the following argument: shut up.
Blue Man Group and those little notes are only part of the story of the Intel Inside campaign, the part that the public sees.
The other part is based on the razor-thin profit margins in the PC arena. IIRC, Intel Inside is a co-marketing agreement. Co-market, play those little notes and display the Intel logo as part of your ad, and you get a nice co-marketing fee from Intel. With next-to-no profit margin, that co-marketing fee just might be your profit, or a large part thereof.
Maybe the days of "You MUST use our CPUs in 100% of your products!" are gone, but I'll bet the days of, "You must use our CPUs in 100% of your products in order to participate in Intel Inside!" are still here.
The living have better things to do than to continue hating the dead.
And all of these are cases of an executing piece of code dynamically creating and executing another piece of code which is exactly what happens in a buffer overflow situation.
However, the number of programs that have a legitimate need to do this is tiny. I'm not sure how this chip will accomdoate those. There may need to be some kind of OS-layer thing with code that is trusted. Maybe the JVM itself could switch modes, so that only when it is actively attempting to write code would that feature be allowed. There are definitely work-arounds to allow JIT to continue working.
As for copy protection, given a choice between having a system which is secure for me and a system which is secure for them, I'll take the system which is secure for me. What about you?
-------
Create a WAP hosting service
Call me stupid, but AFAIK x86 chips have full segmentation support (in protected mode obviously) - ability to define different segment types (read only, r/w, execute only, etc)... For those of you not familiar with it, it allows the programmer to define different types of memory segments, which would allow you to do some pretty interesting things such as defining read-only code segments (so the machine instructions can't be modified in memory), and non-executing data segments (to prevent OS from trying to run code stored in program data/buffers). This would solve the problem, at least how they addressed it in the article.
;)
If current operating systems actually used this in addition to paging (which is what most of them only use now), why would they need to create a new chip? Linux does not fully utilize segmention, mostly only paging. I don't have any resources on MS OS design right now so I can't comment on it... (although maybe looking at the recent source would help some
# fuser -v
#
Scalable Processor ARChitecture.
why can't they just double check their code?
for the same reason cooperative multitasking went out of style: humans.
theoretically a coop multitasking operating system is much more efficient than pre-emptive multitasking. coop multitasking systems (like Mac OS pre X and Novell Netware) require each application to voluntarily give up the CPU when appropriate. That means that every app gets the entire cpu to itself, yielding better cache performance and allowing the app to continue a thread until a good time to stop came along (like, waiting for input or disk or whatever). Unfortunately, that means all programs must be perfect, a bug in any one of the running programs will bring down the entire OS like a house of cards. Or if you didn't release resources just right, your app would appear to hog the entire system and it would LOOK like you crashed everything.
Most programmers are not perfect.
Thus the rise in pre-emptive multitasking, where app programmers no longer get to decide when to give up the cpu, the operating system yanks your thread based on timeslices or some other mechanism outside the apps control. this means your various caches no longer have the "right" data most of the time, and maybe your thread gets yanked 1 instruction short of what would have been a better stopping place (maybe the next cycle was for a well-timed disk access). Some advanced chip features like memory streaming for SIMD ops also get trampled by pre-emptive multitasking, meaning you can no longer prefetch large chunks of data since threading out stops all your streams (this is a problem for Altivec programming.)
But on the whole, by acknowledging that programmers are not perfect (it only takes one bad one to ruin your system), and moving to the "wrong" solution of pre-empt multitasking, we get vastly improved stability and perceived performance. This is also why "wrong" solutions like hardware overflow protection are needed.
A scientist would say you are right, but an engineer would say you are wrong.
Do you remember when the "Intel Inside" logo came out? There was no real competition. (it was the Pentium days) There were other processors, but the Pentium pretty much blew them away. Intel didn't just success on that logo alone, they do have a little bit of technology behind it.
I think it is funny when people say AMD is better. When they say that, ask them why - 99% of the time it will be because it is cheaper (bang for the buck). The other 1% might do overclocking, or read anandtech on a daily basis, or have some highly technical reason - which is essentially irrelevant to the argument. For AMD to be where they are in the processor market, it is nearly a miracle. The only reason is because Intel was comfortable in their position. AMD came on the scene with a comparable product at a cheaper price, and it woke Intel up real fast. They catered more to the "home enthusiast" market at just the right time.
I have a buddy who has worked at Intel for 7 years now, and I always kid him about AMD. He works on the thermal solutions, and has access to the fab floor. There may be some advantages that Intel has over AMD in some areas (and vice versa) but if you have two well put together systems of each sitting side-by-side, the processor is pretty much a non-issue.
My beliefs do not require that you agree with them.
Marking pages as executable/non-executable is old, and it's not the way to deal with buffer overflows. Many buffer overflow exploits, in fact, only modify data (like the saved PC pointer).
The correct way of dealing with buffer overflow problems is to make them not happen in the first place. That means that all pointers need to have bounds associated with them. Unfortunately, both the C mindset and some design quirks of the C programming language make that a little harder than it should be for UNIX/Linux and C-based systems.
The real problem is ultimately the use of C, and the real solution is not to use a new CPU or add instructions, but to use a language without C's quirks. In terms of performance, C's pointer semantics only hurt anyway.
Doesn't it sound strange to modify hardware to correct a software deficiency? Well to me it does. Lemme tell a story ( a little off topic):
I bought a truck. Said truck did not have original bumper. OK, first week i get a flat. No big deal just change it right?. But, without the original bumper i couldn't get to the "mr. Pickup" spare tire let down access port in the bumper, because it is apparently misaligned. Right, so Take the truck back get it fixed. Ok, next week pick up the truck, Bumper has not been re-aligned nothing on truck is modified. I pull out the tire tool to see how it is working to find out that whomever had been working on the vehicle decided it was better to modify that tool instead of really fixing the problem. They had taken the tire tool to a grinding wheel. In roughly the middle of the device they modified it from about half an inch in diameter to about a quarter. Well it does work but I must say what the hell where they thinking about (i bought it from a dealer of course)
Buffer overflows occur because the call-tree is in the same, writable stack as the call-frames (local variables). Furthermore, languages like C make it very easy to define "buffers" that are located in the local stackframe, instead of forcibly allocating memory in the heap.
So, the problem is that somehow (e.g. not limiting the amount of input you read into a fixed sized buffer) you overrun the end of your buffer on the local stackframe with the return address at some point just after it.
You have to know how far an offset the return address is from the start of the overflowed buffer, and where you'd like to put the instruction pointer now. As you don't generally have anywhere else, you put the Instruction Pointer to some point on the stack where you overflowed it. Make sure your overflow includes exploit code, and enough NOPs first to allow for any call depth.
Barricades against this technique:
- random address for start of stack
- non-executable stacks
- forwards-growing stacks
Years ago I went to a presentation on RISC v. CISC architectures. The presenter pointed out that RISC didn't really stand for "Reduced Instruction Set Computing" rather it stood for "Relegate the Important Stuff to Compilers". Why hasn't Microsoft released C and C++ compilers that institute bounds checking? Hell, ADA had this years ago and say what you will about the language it's a damned handy thing to have.
This will be a good thing if it works out, but it will take years for these chips to penetrate the market to any significant degree and once again we are seeing hardware vendors come to the rescue of software companies by creating hardware that has the capability, either in speed or safety features, to compensate for bad programming tools and bad programmers.
cheap labor conservatives - they want to keep you hungry enough to be thankful for minimum wage.
The LISP machines built at the MIT AI Lab had hardware which worked in parallel with the main CPU that checked things like array bounds and also did other types of tag checking, such as automatic runtime coercion of ints to floats and other things that are helpful to a high level language.
Since every object in LISP machine memory had a type tag, many useful operations could be parallelized, such as garbage collection and type dispatch for object oriented function calls.
The problem with languages like C is that they have no object semantics at all, so runtime bounds checking and other goodies don't work very well. The C weenies have everybody convinced that this is necessary to get the highest performance, but they don't realize that with a small amount of extra hardware, all these safety operations can be done in parallel. And since the C weenies influence the CPU designers, it is a vicious circle of bad machine architecture.
Because it's faster and doesn't suck up a lot of memory. It wasn't until recently that John Carmack switched to writting in C++ instead of C for his new DooM ]|[ engine.
By the way... What is (or is there) the Windows equivalent?
Read on. There is specific support for the NX flag on pages. If you boot with noexec=on, then stack/heap/data is automatically protected. If the page fault handler sees your thread because of an NX flag violation, the process is killed.
Caveats: you can't mprotect it back to execute status, and it breaks some software, especially Mozilla/Java/Ada (just like exec-shield...)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The alert was sparked by the discovery that a raft of Microsoft programs were vulnerable to a problem called "buffer overflow", which hackers can exploit to extract private information from a PC.
...
The new AMD chips prevent this. They separate memory into instruction-only and data-only sections. If hackers attempt to execute code from the data section of memory, they will fail. Windows will then detect the attempt and close the application.
So they are depending on Windows to detect the attempt and close the application? Bwahahaha! So now rather than offering Critical Updates to fix buffer overflow vulnerabilities, MS will now offer Critical Updates to fix buffer overflow exception handling vulnerabilities. Ha!
Um folks Sun UltraSparc chips and Solaris have been doing overflow protection for years. This is nothing new. All you have to do is enable it.
This "new feature" for marking pages as having a non-executeable stack is *already* part of the Athlon-64 chips. The New Scientist article was talking about how a new version of XP will begin using it soon--not that it's not yet released.
AMD has already made Intel look bad by getting their 64-bit CPU into the mass-market first, and this feature was implemented partly to provide a facility that some other platforms (e.g. Solaris on Sparc) have had for quite some time.
Actually this is fantastic news. Already, it doesn't matter that Microsofties are dividing by zero all over the place - it becomes an exception taken care of by the built-in structured exception handling and life goes on and the user is never the wiser.
Now we can excerpt even more crappy code. All that's left is a realtime automaton connected to the CPU that spots Microsoft code on the way and automatically gives it a liposuction before feeding it in.
Technology!
They need to hire the marketing firm that produced those hilarious 3dfx commercials...
;-)
/proud to be an AMD customer since the K6II
You know, the ones that started off with the soft voice, "We produced a chip that has the power to save lives, to heal across distances, to end hunger...But then we deciced: Hey, let's use it for games!"
Granted you could be nervous about this since 3dfx went the way of the dodo, but since AMD doesn't make POS video cards that double the weight of your box...they should be safe
"It is seldom that liberty of any kind is lost all at once." -David Hume