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."
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.
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.
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 !
Anytime you change the architecture of a chip there will be side effects. It is inevitable. I am interested to see what the repercussions might be it terms of code, performance, and even reliability. If they implemented this well, perhaps these side effects will be minimal and unnoticeable, in which case this could be a major development!
Forecast for tomorrow: A few sprinklings of genius with a chance of DOOM!
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!)
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
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.
My guess is that many applications use self-modifying code as part of their anti-piracy/anti-reverse-engineering protection.
True warriors use the Klingon Google
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.
...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.
Many UNIX versions already support this kind of protection and it's on by default. Good portable code deals with it. If I remember right, you have to use mmap to get a special section of memory that you can both write and execute.
self modifying code is one thing ... but there are real apps have needs to create code on the fly and execute it (great examples are Java JIT compilers, and wonderfull valgrind) .... on the other hand a FAST, standard way to set the pages protections on some newly created code from RW- to R-X would be appropriate in these cases
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.
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.
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.
Not CPU's. AMD doesn't make those motherboards, so it's not their fault if they don't implement the features.
This will be the year of sloppy coding.
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
you can spin it as a type of protection.
joes love protection.. maybe include some sort of armament analogy. like its blows buffer overflows away like a nuke! or something
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...
DOS is better than a remote root exploit. When your machine goes down you know you at least know about it.
As you say this is already supported by an appropriately compiled Linux kernel or XP-64 on the A64 & Opteron. The wider benefit for all of us is that this is to be included in XP SP-2 which will hopefully become endemic sometime this year. See this eWeek article . At that point this becomes an excellent marketing tactic for AMD. I haven't examined the IA32e documents for myself yet but those who have seem to think Intel have left out support of the NX flag - see sandpile.org. If this is true then Intel are handing AMD a real advantage as far as consumer marketing is concerned. Even I could spin that so that that it looked like more of an advantage than 64bit capability which to be honest is a real hard sell as far as your average consumer is concerned.
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.
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."
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
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.
Try to get your facts correct. Corrections:
1) If its in Prescott, Intel isn't saying so.
3) It just makes things harder to exploit, but that true of everything.
4) BS. You have to switch to PAE mode, but that isn't 64bit mode.
5) It only requires the kernel change, no apps need the recompile.
7) It will typically change exploits from allowing elavation of privelege to a DOS.
[i]I can barely get my clients to understand why they need SSL[/i]
With SSL you get the lock picture. Without SSL you simply don't get it. Everyone wants to get it, but that takes SSL and not everybody can have SSL. Do you want brand name SSL for a low low price?
Gotta have the lock (tm).
Rod Taylor
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.
You have to understand that in the old days, these sorts of things weren't considered "bad coding practices", they were considered "Super Elite Hacker Tricks". Early PC programming was always to the metal, using every trick in the book.
The hardware was ridiclously constrained -- the functionality of something like Word 4.0 (which ran on a 1MB Mac Plus) compares to modern word processors (which need 50MB of RAM and a Pentium II). Someone had to hack like crazy to get that stuff to work, and they were probably fully aware that it could blowup later.