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.
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).
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.
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).
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
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.
Explain to Average Joe that his computer will be protected from (some) crashes and (some) computer viruses..
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.
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..."
Some of today's problems are really just side-effects of the x86 legacy. If you're willing to break binary compatibility, fixing problems is really, really easy. For example, there's no law that stacks have to stupidly grow downwards in memory so that an overflow ends up overwriting older stuff on the stack space, instead of overwriting in the direction where the unallocated space is. And indeed, on many architectures, it works more sensibly. So even if you don't protect against overflows, their damage doesn't need to be so severe.
But by the time it became popular for personal computers to be connected to the internet (and thus, overflow protection started to become really important), it was far too late to fix the problem, because too many people were locked into x86.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
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 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...
Not CPU's. AMD doesn't make those motherboards, so it's not their fault if they don't implement the features.
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
They did. Mainframes and the like have had protection from this sort of hack for ages. AS/400s have object orientation support built into the hardware, and a data object (which is what a stack or buffer would be implemented as) cannot be executed as code, no matter what. The hardware will not allow it. Nor would the buffer be allowed to grow into a code location.
We're living with hardware and software architecture decisions made in the 1980s, when PCs were still considered toys.
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
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
#
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.