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."
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
Would be "Hey we'll protect against the most common Windows exploits!"...
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).
LOL, this was modded as insightful???
"buffer overflow was built into a processor" That's a beaute.
This type of thing will not affect the speed of the processor in the least. It is just adding support for a combination of protection bits (RW but no X) that should have been available since the 386, but were not because it has been a fundamentally lame design. In fact you could always express these protection bits in the page tables from the getgo, but the processor was too lame to actually support them. Of course you couldn't just change this "feature" because anyone would that did would break true x86 backward compatibility.
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?
Intel's 64bit processor (which they will market as 32bit with 64bit extention) lacks NX bit and I believe instructions necessary to implement this extra level of hardware based buffer overflow protection. It instead needs to be emulated in software which will unfortunately be slower. This may force the BSD/Linux brands to ship binaries with the least common denominator, meaning avoiding AMD's better instructions completely in order to be compatible with Intel's crippled chip.
This will make a huge difference in security.
Hopefully for the good, unless it creates a scenario where people think this chip protects them from everything and people update their software even less. Not all problems stem from overflows so if this technology is interpreted incorrectly, it could have negative implications.
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.
Until now, Intel-compatible processors have not been able to distinguish between sections of memory that contain data and those that contain program instructions. This has allowed hackers to insert malicious program instructions in sections of memory that are supposed to contain data only, and use buffer overflow to overwrite the "pointer" data that tells the processor which instruction to execute next. Hackers use this to force the computer to start executing their own code (see graphic).
I'm pretty sure that the segment selectors of 80286 and newer processors have bits to indicate code or data, but Microsoft simply chose not to utilize this mechanism, instead opting to use a flat memory model and thus one small set of selectors. Makes me wonder if this new method is intended to similarly mark pages rather than segments.
This mechanism won't help, however, unless the stack is treated as data only. I vaguely recall cases where kernel code writes short machine language snippets to the stack and then jumps to an address in the stack; allowing this behavior (coupled with using the stack for data buffers) is the basic buffer overflow problem.
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
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.
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.
Like IBM with OS/2, they have the better product.
And like IBM with OS/2 their 3rd party vendor support is poor. Bottom line is that they are still plagued with inconsistent chipsets and motherboard makers. AMD should offer an AMD manufactured motherboard with an AMD chipset just like Intel. That would be a big boost to their reputation for stability.
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.
You must have misread my post as I clearly stated it wasn't C++ that was the problem but the way people used it. Most (every?) functions that is still around for backwards compatibility and runs the risk of buffer overflows has an alternative that can be used to prevent buffer overflows by limiting the amount of whatever it is you are doing.
The i386 (and I think even the 286) have provisions for 4 levels of privledge for code. Programs at level 0 can do pretty much anything, those at level 3 can do very little (e.g. not access other processes memory and only call higher privledge levels via special 'call gates').
Levels 1 and 2 are intended to be where the majority of the OS kernel sits, this would mean that something like a device driver can't over write the scheduler. But no OS to my knowledge uses this feature of x86. If this were done there would be less chance of kernel code causing a system wide crash or any buffer overflow which manages to hook into the kernel actually being able to cause as much damage.
The entire x86 range also differntiates code segments, data segements and stack segments(the cs register and the d/e/f/gs registers).
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
PCI clock locking is to prevent the bus speed from drifting. Seems that most current AMD systems are running a 33mhz PCI buss +/- 3.3Mhz. Thats enough to cause crashes. True you see this in overclocked systems more then anything else. However over time the PCI buss speed can change in non locked systems due to thermal expansion of the circuitry etc. These are not big issues. In fact for home users they are non issues. However when I need my server farm to be up 24/7 and dont realy NEED the extra speed the AMD chips just dont look to good.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
there is absolutely no reason for text to be improperly spelled! There are programmatic tools, such as spell checkers, which would mean that typists never have to manipulate characters in improper ways. /sarcasm
Yet typographical errors do still occur, and often that's all the difference there is between a buffer overflow and good code. Surely there should be more QA involved in code than in a web post - but typos escape publishing as well.
The primary difference is that when a manual has a wrong spelling, or improper grammar, the failure is not catastrophic.
Using the proposed chip feature wouldn't prevent buffer overflows the way proper array-checking does. It would simply prevent arbitrary code execution from a data page - making the failure less-catastrophic, and more in line with its publishing analogue.
This chip feature is in fact superior to any comparable compiler/language feature - because it would hold all code (regardless of source) to the same standard.
It's frightening that even vendors believe in marketing. I meet with vendor one day to discuss supplying us with generic computers. I told them that most of our desktops were Durons. They gasped and stated they could not recommend such things. Stating that they would quote us Intel to "ensure stability". I asked them to cite proof that AMD systems were unstable. They could not but implied that it was common knowledge.
UNIX/Linux Consulting
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
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)
It's been implemented in Linux since about 6 months ago, at least on the amd64 branch.
m l
http://www.x86-64.org/lists/discuss/msg03469.ht
This is not going in to make computers more secure, avoid worm attacks, or any other reason of consumer protection. This is going in for one reason only: to support Treacherous Computing platforms such as TCPA, Palladium, and NGSCB. After all, crackers breaking into consumers computers is one thing, but consumers trying to trick their computer into giving them access to their own data is quite another. The fact that it can also be used to prevent real security exploits is simply a side-benefit that will help them encourage upgrades.
I believe this is already in Linux - see x86-64.org where the porting was done. I recall lots of discussions about the effects of non-executable stack about a year ago. Linux fans should have been touting this for some time as an advantage over the competition, even if only on AMD64.
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.
PCI Locking and more specifically.
The problem was never so much the processors as it was the motherboards. Cyrix chips were great on boards that supported them well. Unfortunately the cheap processors were almost always stuck on dirt-cheap motherboards using a POS power supply and every other crappy component people could find. This was especially bad when Cyrix was trying to push technology forward by using 75MHz bus speeds when Intel was only using 66MHz bus speed.
Crappy motherboards continued to plague AMD for ages, even up to today where VIA still hasn't figured out how to write drivers properly. Fortunately for AMD they now have nVidia laying all of the older chipset vendors to shame by doing a better job on their first shot than Intel/VIA/ALi/SiS managed after 10 years.
As for the clock speed thing, AMD just replaced one totally meaningless number (MHz) with another totally meaningless number (model number). It was a termendously successful idea though, boosted their sales a lot because most people like big meaningless numbers better than small meaningless numbers (compensating for something?).
This could still break some apps which rely on executing some area of memory that they didn't mark as such, but you could just make an exec-time option to run that program without protection.
I must be an early adopter, because my processor already detects when your overflow buffers. Ever hear of immunix, the linux distribution with all binaries compiled with Stackguard protection?
What about libefence- the library that detects memory overwrites and underwrites and exits.
What about BoundsChecker?
This isn't new...its just another way to do the things that we don't do anyway. Its not going to force anyone to compile their software to use these features, and thats part of the problem.
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.
...
Well, no-execute-pages has been fully documented in the publicly-available x86-64 (now AMD64) Programmer's Manuals for two years now.
Now, if I could only get some documentation on that new-fangled Win2K operating system
I am not a sig.
Anyone think HP will come out with an intellectual property noise ?
From the P-Pro on up, Intel CPU now support microcode updates to fix or work around the bugs. Once a motherboard manufacture knows of the CPU errata, they simply update the microcode into a newer BIOS revision. By flashing your BIOS to the latest rev (assuming it contains updated microcode), you will have fixed the CPU problem.
Also, AMD CPUs support microcode updates as well.
Life is not for the lazy.
Ahh yes, this sounds familiar... In protected mode on the x86 (with segmentation enabled), far memory pointers are 48-bit, are they not? 16-bit segment selector + 32-bit memory offset into 4gb virtual address space. That is something of a problem, not being able to fit a far pointer into a general register (kinda makes indirect memory references via pointer hard, don't it?).
D /0,,30_2252_875_7044,00.html) , AMD claims that "In 64-bit mode, the AM64 architecture supports only the flat-memory model in which there is only one data segment, so the effective address is used as the virtual (linear) address and far pointers are not needed." (page 23).
However, the new 64-bit architecture as proposed by AMD (I don't have Intel's specs) seem to suggest this might not be a problem anymore. The AMD64 Architecture Programmer's Manual Volume 2: System Programming has lots of information and I must admit it's a lot to read, but from what I gather would this not be an issue anymore? 32-bit memory offset (upto 4gb virtual address space) + 16-bit segment selector can easily fit within a 64-bit register, however I'm not sure if the CPU is designed to handle such things. From the Application Programming Documentation (at http://www.amd.com/us-en/Processors/DevelopWithAM
So maybe I have indeed answered my own question... segmentation as it was designed for will not easily be utilized... If so, would anyone with any sort of CPU architecture design/experience possibly give any reasons for this? Would it just be too difficult to modify the instruction sets and architecture to easily accomodate full segmentation support?
# fuser -v
#