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.
Would be "Hey we'll protect against the most common Windows exploits!"...
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 !
AMD could use a push right now, since their 64-bit chips are big, their wafers are smaller, and their process is larger. Check it out on Tom's Hardware. I'm not in the market for a new cpu for 2-3 years, and I'm hoping that AMD will have pushed the market to a more competitive scenario by then. Buffer overflow protection released ahead of Intel looks a good move for the processor underdog.
If my answers frighten you, stop asking scary questions.
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.. yes Joe.. and it would do your dishes ;-)
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!)
I was just today shopping for components to build a new router/firewall machine for my home network. I really wanted a non-x86 architecture that supports page-level exec protection like powerpc or sparc64 for use with OpenBSD. Unfortunately there are no reasonably-priced consumer boards other than x86.
Maybe I'll wait until these new AMD chips come out to build the router.
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.
...until Intel gets some execute protection bits into their chips.
There's no replacement for careful coding.
Oh I'm confused... so MSFT are the cause of the buffer overrun bugs in Linux?
errm. is this just an x86 problem?
either the PowerPC does it, or the OS must handle it - as AmigaOS 4 already makes sure that data and code segments are kept seperate and cannot be cross contaminated.
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
Since you have to rewrite the software anyway to tell the hardware what the buffer boundaries are, this doesn't sound like any security improvement over just rewritting the software. Only improvement is that checking bounds is a little faster.
"Freedom means freedom for everybody" -- Dick Cheney
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
That had better be humor, or else I think I might cry...
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.
Oh like theres never been a buffer overflow problem in linux... Talk about a cheapshot.
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
But then it says:
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, which one is it? Can any OS use this new feature in the hardware?
Rosco: "If brains were gunpowder, Enos couldn't blow his nose."
So, AMD is willing to take the liability for microsoft (and others) bad code?
Are they really trying to say that it's safe to run windows and their boxes are unhackable?
how long till they are hacked and in expensive lawsuits??
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.
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?
The Opterons and A64's have the ability to mark the stack as non-executable. This will stop common buffer overflow exploits, which run code off the stack to gain privileged execution.
But, the OS needs to enable this, and I think it may only be available in 64 bit mode. The article mentions that the 64 bit XP will use it. Does anyone know if the x86-64 Linux kernels use this feature?
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.
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
Look,
Anything that AMD does only helps Intel. Intel put a ton of CASH into amd to prop them up because Intel was being investigated as a Monopoly..WHICH THEY ARE. This is the same as MicroCrap giving SCO 50mil to sue Linux advocates with.
Intel will continue to support AMD, allowing them to have a few items of note to keep em going. This allows Intel to earn BILLIONS of dollars/yr with 95% of the processor market.
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.
Reality: Financial institutions are the slowest to adopt technology of any business sector.
You probably think those "85,000 desktops" are running WinXP - more like OS/2 or DOS...
Microsoft hasn't been known to set flags consistently. Windows XP refuses to work properly with SCSI hard drives because Microsoft told manufacturers that they would set flags one way, then set them a different way in XP. Drivers had to be rewritten, and users only get proper performance when they use *special* drivers written for XP.
If my answers frighten you, stop asking scary questions.
Insightful? Please.
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.
Nowhere in the parent post does (s)he come close to saying that. It's obvious that there will be a performance penalty for this built-in "feature", which is one of the reasons why I *don't* like it. The parent is suggesting that buffer overflows are caused by faulty programming, and not by faulty chip design. Somehow, you've managed to mangle that into "programmers can continue to write faulty code, and other people should be forced to fix it." How you did this, I don't know, but it clearly shows a lack of understanding on your part.
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.
Ok, so I haven't read detail specs on this.. But my guess is that the compilers will need to be changed to implement this.. Then any software would need to be recompiled.. No changes to the source for the app, but a recompile. The compiler would be the one that knows what is data, and what is code, so it should be able to flag stuff accordingly..
Slashdot is like Playboy: I read it for the articles
It's not just MSFT. It's everybody. You could make that statement about the Apache Foundation.
Surely intel could profit aswell?!
IHMO, available cycles should not be sacrificed to the overhead this will introduce when the problem is sloppy programming, whether it is programmer or retarded-i-can't-plan-manager induced.
By the way, anyone caught using try-catch-finally clauses for 'liberal' conditioning need be hung by way of testicles or fallopian tubes.
HAD
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.
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.
Can't we already do this by marking pages non-executable. The openwall project marks the stack non-executable which prevents many types of buffer overflows. What's new and different with this processor??
I don't understand this.. modern operating systems already mark pages with individual write and execute permissions. Buffer overruns are exploitable when they occur in pages which are marked both writeable and executable, such as the stack... ?? I don't see why this requires new hardware to fix.
gets() be deprecated already?
I mean, if it is inherently unsafe, why keep such a function around?
If you ignore the other uses of a tool, does that make the tool less useful, or you less useful?
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?"
This isn't anything we haven't heard already. Microsoft plans to integrate a 'ProPolice' like feature into the next version of Windows for CPU's that appropriate (per page) memory permission flags. The Opterons have it.
It is the same feature that makes OpenBSD's overflow protections work so well on Sparc systems.
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.
ummmm remember propolice stackguard, there are a few other companies who make this. OpenBSD renamed it W^X it is all variations on the same idea. Have the kernel flag certain memory areas as r-w-x and then enforce it. The problem with x86 was that the memory space is NOT flat. You have to use ES registers and the like to calculate where you actually are in memory, This is why windoze and linux have trouble with it. It is a pain in the ass the rearrange the layout of all known memory in a running system and dynamically flag r-w-x...
64bit cpu's have a flat memory space, ssoooo everything above 48MB is RO, everything between 0 and 16MB is executable etc.etc. It becomes a VERY simple problem of executable code must live in the executable memory pages. Buffers from ANY kernel or application must live in the RO memory pages period. now you dont have a buffer problem. because overflows just mess up other RO memory and IF they try and do more they get SEG-FAULT.
end of story. nothing to see here (except the usual microcrap touting new technology that everyone else has had for a decade.)
Still looking for hard tech on what exactly they're doing - I honestly don't know. However, if you could control one heap variable and overflow a stack-based buffer, would setting the stack to return into the heap variable and execute code inserted there still work? Seems like it might - a much harder-to-find situation than just a single unchecked stack buffer, but definitely not unheard of.
I write code.
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.
The hardware is to divide virtual memory into seperate I (instruction) and D (data) spaces. I has nothing to do with preventing buffer overflows from happening. It does nothing with regard to bounds checks.
It does prevent buffer overflow viruses that rely upon positioning machine instruction in a place they will be executed. This is because the instructions will be in D space and can't be executed.
This will be the year of sloppy coding.
how come every post that mods itself -1 flamebait gets modded up to +4 or +5?
I'm gonna pre-mod this post to -1, flamebait too..
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
Wasn't there a version of the beasties that implemented "X ^ R" already? I remember looking at some diffs which, for the Intel version, had complaints about how this feature wasn't supported at all on x86's so the whole thing was reduced to "NOP"s and "return true;"s -- just can't remember which one. At this point my national pride kicks in and I remember that it was a fellow Canuck who was checking it in (did he build it himself as well?).
Eventually Windows will support the good things others are already doing... and get all the credit, too.
cheers...ank
Still hoping for Gentle Treatment...
Excellent! Now they just need to develop a chip that protects against id10t and PEBCAK problems.
Quidquid latine dictum sit, altum sonatur.
The question will be whether their PR department can spin this...
Perhaps AMD could create a musuem of vintage blue-creens, all with less-than-subtle associations of the "Inel Inside" logo.
dubito ergo sum
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
One of the inside jokes among hardware designers/architects is that we're there to fix the brain-dead ideas/practices of software people.
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.
Damned good question. Somebody confirm or deny this idea
-kgj
-kgj
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
While helpful, consider the uptake curve.
There won't even be 10% penetration for a number of years. So lots [10,000,000s] of machines will still be vulnerable for years to come. It will help with some of the newer machines, but most of those will be running newer OSs that have many/most of the current crop of buffer overflow exploits fixed.
Those win 95 boxes will continue to be turned into Zombies for years to come...
Remember back in the 60s and before, all cars leaked oil?
As the owner of many 60s cars, I can definitely say "No. I don't remember that." As a matter of fact, I have never owned a car from that period that leaked oil. The only car in my household that leaked oil was my wife's 97 Jetta.
I own(ed) Mustangs, Novas, Chevelles, GTOs, Chargers, a Riviera and a GS (OK, the GS was a 70). None of them leaked oil.
Are you British by any chance?
Oh I'm confused... so MSFT are the cause of the buffer overrun bugs in Linux?
Please, do not be confused, do not worry, you simply do not understand the breadth and depth of the evil of Microsoft and its minions.
Microsoft created Linux in an effort to prove the power of the dark side. Anonymously contributing code deemed too obfusticated to be wrong and therefore correct, they have managed to implement bugs that will only surface at moments when Microsofts code appears to be under threat. These bugs in the Linux code are so vast in nature, and the regularity of their appearances(hence the continual bug fixes and revisions in the various distributions), was thought to be the ultimate proof of the efficiency of a closed source model.
Using this subterfuge however was deemed worthless in the face of regular system crashes and security problems becoming the norm and therefore acceptable.
So they turned to plan B.
The next chapter of the story.
The Empire Strikes Back.
SCO.
I guess you didn't even read the article title:
.. perhaps you should take an introductory course on operating systems and study where M$ falls short on their inherent design. Oh, and btw - I'm in my mid-30s and frequently use M$ to abbrev Microsoft as it seems to accurately describe their primary design goal. Perhaps a little more understanding before you run rampant on your pathetic link attempts and criticisms.
"Chips to ease Microsoft's big security nightmare"
The issue is really on the O/S since most other O/S's provide mechanisms to do a non-executable stack. (Solaris, some BSDs, not sure about linux). Yes the exploit happens with an application, but guess who provides the framework for the application to run on the hardware
hp-ux already does this in software (pdf doc): http://tinyurl.com/2w2rt
Although, this can mess up on JDKs = 1.2.2.
I put the 'fun' in fundamentalism
I think you're confused :) (Though the mods think you are insightful, I guess that says as much about them as you.)
There is no way to do this at the motherboard level. It needs to happen in the MMU which is part of the processor. And it isn't specific to buffer overflows. In fact, it does not prevent them. What is does is allow the operating system to mark memory as readable without making it executable. Other processors can already do this. And there are known kludgy workarounds which are implemented in OpenBSD and Solar Designer's Linux kernel patches which make it work even on broken Intel CPUs. AMD and Intel are simply implementing the page table protection bits the way they should have been implemented back when Intel created the 386.
BUT you have had to implement segmented memory management to get it.
The problem has always been that the execute flag has only existed in the segmentation registers.
This change puts the execute flag on the PAGE rather than the SEGMENT.
The segmented mode is SLOW when you combine it with paging activity (you get a fault on a page, and you have to modify both the page tables AND the segment descriptors for things to work. Going through both mapping registers (page and segment) causes a significant speed reduction in memory access. It also gives you a larger physical memory range... (cache collision penalties too)
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...
Well, the number of spam relays and viruses that rely on buffer overflows in IE and OE should be enough to give them a good start anyway....
Your reference to Microsoft as MSFT unveils that
you are really a Microsoft Stockholder.
Your previous post was more of an advert for
Microsoft than an actual statement based on
FACTS.
On that note, perhaps something similar, IE it won't protect you from overflowing your cup of coffee?
This sig no verb.
Adding read permission for a page traditionally also grants execute permission. There are ways to work around it but they aren't pretty.
if they have built in buffer overflow protection how is windows going to "operate" normally?
Step 1: Collect underpants.
Step 2: Release new consumer chips with built-in buffer-overflow protection.
Step 3: Profit!
Several architectures (sparc, sparc64, alpha, hppa, m88k) have had per-page execute permissons for years.
See This BugTraq posting by Theo de Raadt
Just like how fast processors and excess memory has allowed for programs to become sloppy in their code writing and optimization, adding this feature within a processor will allow for even less experienced programmers to code large projects.
:)
Just think about all of the impressive stuff that goes on in embedded systems, and think of the size. Then think of all the stuff you do on you computer and look at the size.
I'm not worried. I run OpenBSD.
I submitted this story over a month ago, but it was rejected by the editors. The technology is already available in the Athlon64s, and Prescott versions of the Pentium4, but require service pack 2 for windows. Not sure if linux supports the feature.
Vote for Pedro
Great. So AMD has apparently rediscovered the Harvard architecture, or a variant thereof. (The "virtual" Harvard architecture?) [ http://en.wikipedia.org/wiki/Harvard_architecture ]
Has it been adequately demonstrated yet that there is in fact nothing new under the sun? No? Okay.
For a bonus laugh, I wonder if they're going to get a patent on this "novel technology".
I am Chaos. I am alive, and I tell you that you are Free. -Eris
The first network based worm was written about 1975 by HP. The engineers had just finished reading "Shockwave Rider" (John Brunner - 1972) and were curious if they could make a worm.
Their target was the buildings network of HP systems, which were setup to run diagnostics from midnight to ~5AM. Their worm was to run around the hosts, collect statistics data on the diagnostic, and return that data to the lab host. It worked for several days before they terminated it (several hosts couldn't handle it and crashed, which made them unavailable in the morning).
i can't belive how many people are buying into tcpa/ngscb/etc to improve microsofts security. it is not the hardware thats the porblem, the poor codeing in the software is what allows buffer overflows to compromise a system not a hardware defect.
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.
First off, Windows needs to get rid of the 16-bit subsystem. You could run NT 3.51 without the 16-bit subsystem, and I used to do so as early as 1997. In NT 4, there's no obvious way to turn it off, although I'm sure there's some obscure registry key you can alter.
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."
The whole idea behind this isn't to prevent programs from accidentally overflowing the buffer. The idea behind this security measure is to prevent people who write viruses from overflowing the buffer. You can ask the people from MS to be careful with their coding but... when you have an OS that big and bulky it's a tough thing to do. They shouldn't have as many holes as they do to plug up but security holes are almost inevitable at that scale. AMD is saving us from Micro$oft's sloppiness and countless patches. Be thankful!
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.
AMD64 pages have an execute permission bit. That just means that you can make your buffers non-executable (this can be achieved with segment level protection on normal x86 cpus). You can still have a buffer overflow exploit that doesn't execute any code. For example, consider someone writing a 104 character name to the following structure:
struct user {
char name[100];
int can_write_other_peoples_files;
};
Non executable buffers don't help here. True buffer overflow protection would be some kind of hardware assisted bounds checking.
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.
I want to know if there will be a way to turn this feature off on a per-application basis (presumably through a call to the OS), as there are rare instances when self-modifying code can be incredibly efficient.
Adding support for a different combination of bits should not be a performance drag. I agree the parent was confused (programs accidentally having buffer overflows in their inbuilt operations vs. deliberate buffer overflow expoits), but hey, they criticised 'M$', so they got modded up! You must be new around here, etc.
You're right, as far as I can tell. At some level, code is data. That's kind of the whole point of computers. If you can never write data that can be executed, you can never run a program. That's not to say some of these schemes (W^X and so on) aren't useful, nor to say that they're not kind of a buzzkill (self-modifying code is fun!).
When all is said and done, just as you can't legislate morality, you can't enforce good programming.
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
Perhaps the parent was short on MS? Or as someone who knows the ticker ID is MSFT maybe your post is nothing more than an advert for Microsoft rather than an actual statement based on FACTS?
I disagree that this is out of the coder's hands. If your program is doing that many memory allocations on the stack, you're better off using a dedicated memory manager and using the heap instead. Then you can turn on array-bounds checking on your memory manager during the compile phase, and capture the buffer overflows.
IM(NS)HO, programmers shouldn't use C unless they know assembler. C is really just an Assembler abstraction layer that standardizes the appearance of the hardware while still allowing full access to all system resources (Subject to OS limitations).
It's kind of analogous to driving a standard shift car vs. an automatic with cruise control. If you don't know how to use the clutch pedal, you're better off with the automatic, even though you might wish you had the acceleration of the stick shift. Maybe developers should be fined for coding C without a license?
We are the 198 proof..
Volkswagen didn't build any more Jettas by 1997 - they're called Ventos now. So you're obviously lying. Moron!
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
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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
#
Does preventing executable stack/data pages prevent a large number of bugs from being exploitable, or does it just stop existing exploits until they are recoded to use other techniques (like return-into-libc)?
In other words, does a properly used non-executable bit make a large number of bugs impossible to exploit, or just a bit more difficult?
My Web Page
...you linked to this: http://http//www.catb.org/~esr/jargon/html/P/PEBKA C.html
which in my book ain't a valid url, and thus you have proved that in your case PEBKAC
I am NaN
Anything to keep the AMD running smooth is a damn good thing in my book. I use the AMD Athlon processor and in several different ways to me, it outclasses and outmatches any Pentium processor. I'm sure that statement is very arguable, but I feel that AMD processors, even though louder, have a lot more power to them. Even if they burn out faster than an Intel processor, it's just good to know that for that shorter of a time it was running, it did it's best to give me the best experience.
I don't hate Intel or any of their processors, as all of my friends use them, but I use the computer for a lot more than just programming, chatting, and downloading -- I'm a hardcore gamer also. If my claim can be proven wrong with technical details, I'd love to hear it. I'm all ears.
"Instant gratification takes too long." - Carrie Fisher
You are talking about supervisor modes. This has nothing to do with that unless you are talking about overflowing a buffer in a device driver. What the AMD press release is talking about is applications: userspace, or level 3 in Intel terminology. Userspace isn't allowed to muck with page tables with or without AMD's change. It's simply not relevant.
And as for OSes that used it OS/2 and NT3.51 both used it. OS/2 is dead. And NT was redesigned for speed so it only uses the two levels.
Theoretically there is no need for more than two levels because the operating system, being in full control, can divvy out the extra priveledges as system calls. See SELinux for an example of very fine-grained control and separation.
I read that as "Butter Overflow Protection." :P
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.
After undusting my 1987 386 reference, it clearly states that segment registers then could distinguish between read, write and execute rights, and that it is impossible to give a segment both write and execute rights. So clearly Microsoft had the tools to create a memory manager that would prevent buffer overruns for more than 15 years. But they were not used so that Windows NT would be compatible with the Alpha and PowerPC.
On the other hand, if you want to write a JIT compiler, you need a way to turn data pages into code pages. So this neat extension will make it harder, hopefully much harder, to exploit buffer overflow bugs, but it cannot prevent it completely.
Just license the Nascar name and yes, average Joe will make a point to buy it.
Sad isn't it
.sigs are for post^Hers.
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.
nt
Over an intel celery any day! Those guys really need to read up on the processors.
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)
The late Peter Gregg, whose nickname was "Peter Perfect" due to his skill and attention to detail, was an extremely successful sports car racer and multi time IMSA champ.
On the street he always drove automatics because he felt they were superiour technology for the application.
You'll find that where the rules allow all racing cars now handle their gear changing automatically under computer control, because the computer and robotic systems can do it better than any human. In fact, where the rules allow and the technology is available, constant velocity transmissions are prefered and no "gear change", per se, takes place at all.
If one can create a hardware architechture which simply refuses to overflow a buffer, what possible point would there be in not doing so?
Do not virtually all high performance cars these days, including racing cars where the utmost in performance is required, make use of rev limiters to prevent human control from damaging the engine?
Once upon a time my favorite programming tool was called a "soldering iron." I still make use of said device for peripherals. I'm not entirely unfamiliar with low level hardware based issues in programming.
Once upon a time you also had to pour your own babbit main bearings for your car. To start the car the first step was to drain the oil sump, heat the oil in a pan on the stove, replace it, then hand pump the oil into the engine, then hand pump fuel into the carb, then hand crank the engine. We call those times "The Bad Old Days."
What a computer can do better than a human is the legitimate field for using computer power.
The problem comes only when people use computers to do what people are better at, thinking.
KFG
I remember the early '90s when there were some Cyrix x86 clones that were having issues, and there were some concerns about AMD. AMD busted through that for most of the people who know what's what, but the general public still has dim memories of that.
Just last week, my father told me he was buying a new PC for my stepmom. He was intrigued by the low prices on AMD Athlon XP systems, but he remembered that they had compatibility issues. It didn't take that much reassuring to get him to go for the cost savings on the AMD, but it did take some and from someone he knew to be unbiased (I have a p4 2.4 laptop and an AMD64 desktop at home).
A lot of people like to attribute the sales gap to Intel winning the battle of the megahertz myth. But there are lots of Joe Consumers out there who pay the Intel premium because still think that an AMD chip might crash or spit out garbage in situations a Pentium will handle with ease.
Until now, AMD has been seen by many as a company that copies Intel's technology... poorly. If Intel adopts x86-64 and then this, they need to spin themselves as the company that Intel is copying... poorly.
-Gregbr>
Start a happiness pandemic
I love your thought. AMD should use it in an advertising campaign.
Contribute to civilization: ari.aynrand.org/donate
Moderation +4
70% Insightful
30% Interesting
Mods are on crack, waste your mod points on other stuff, other similiar posts were made to the same grandparent, we got his post modded to oblivion.
+1 maybe to my post, but +4?
gahhhhhhh
I didn't even provide any actual useful info, I just wanted the mods to pay some attention.
</rant>
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.
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.
Why should you care about that? I'm a consumer, to me what matters is that AMD processors are cheaper and faster. They could be losing money for all I care. I think the financials show that for the past few years they've been losing a couple bucks for every processor they sold, although they aren't right now.
but like I said, it doesn't matter. Right now AMD stuff is a better buy, so if I was buying now that's what I'd buy. I don't know enough to be an analyst, and most analysts don't either. I do know where to get the good stuff, and right now, that's AMD.
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.
mprotect(2).
This syscall exists since about forever and is pretty standard on *nix platforms. Any well written on the fly code generating code is already relying on it.
It's not exactly like you are the first to foresee the problem...
Problems like buffer overflows and memory leaks are due to choosing one's programming language poorly. Any programmer writing high-level functions who needs to call malloc, for example, needs his head examined. C and its ilk should be relegated to only the lowest of low-level programming needs. Then, with a good low-level API, mundane issues like memory management, bounds-checking, and garbage collection can be solved once and for all and free the programmer to do his work without generating these kinds of security issues.
Better computer languages that manage such things transparently abound. Why do so many people still use C?
If you're a large company that doesn't mind taking advantage of Mom and Dad or Grandma and Grandpa back at home, you'll tell them they _need_ this new great technology to prevent "Evil Hackers" and all the other evils from taking over their computer. And they will inevitably buy it because "They said we needed it!" But since it's not a real concern among mainstream users, they will not need this overflow protection, so there are only going to be the smaller companies and individuals buying that know it's not necessary to have. (But they'll buy it too for bragging rights.) This should sell pretty good in a year or so.
-----
Make Love not [Browser] War!
See mprotect(2).
This syscall exists since about forever and is pretty standard on *nix platforms. Any well written on the fly code generating code is already relying on it.
It's not exactly like you are the first to foresee the problem...
I think I just made a dupe comment...
By the way... What is (or is there) the Windows equivalent?
Will having this kind of hardware 'protection' simply lead to sloppier code writing? "Sure my code is shite and full of security holes, but what do I care, the processor will catch it and prevent trouble." What ever happend to "we'll fix it in software" ?
It CAN be done - In Switzerland, crime is "Verboeten" so they don't have any crime there :-)
Maybe the answer is to write all software in Switzerland - sure it costs more than India but WTF
OpenBSD's W^X (magicpoint slides) and Linux grsecurity PaX both use that on x386 but it has its limitations, think for example that every shared library has its own code and data section (to oversimplify) and you have to do heavy manipulation to cram each part in the right segment... Having a per page protection is way better, more convenient and do not sacrifice usability for security (forget Java with PaX, OpenBSD gets by being slighly less secure, but at least not breaking well known Unix semantics like PaX...).
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
...it made me laugh at any rate! ;o)
:o)
Not wanting to be a word nazi, but actually: Ain't isn't a word, but it is a contraction that was first used in the 1700's. Quite an interesting read.
I am NaN
If you remember there was a Virus "chernobyl' that destroyed a computer's BIOS besides cleaning the Harddisk.After that outbreak, there was a virus protection embedded on the motherboard.(eg. Trend)Would this protection compare to something like that?
More importantly would it be really that efficient so as to block all kinds of buffer overflows?
Lord of the Binges.
With some documentation here: http://pax.grsecurity.net/.
BTW, reading on PaX you'll probably stumble on them badmouthing OpenBSD ("them" most likely being fanboys than developpers), this childish attitude from a certain base of users do them nothing but harm...
...with the kernel patches from http://www.grsecurity.net. Adds support for real acl's, chroot enforcement and lots more hardening of the kernel in general.
I've been using it in a shared hosting environment so that I can allow my users to have sftp only access whilst being jailed into their home dir.
I am NaN
To have the code jump at some unintended place, like that $HOME environment variable where you conveniently put your shellcode. What happens when the section where environment variables are is not executable as it should be? Program segfaults instead of the machine being owned...
It'd be nice to prevent buffer overflows in the first place, but errors do happen and having a single line of defense is a really bad idea if it is ever breached...
The good attitude is do the most you can to prevent buffer overflows (by any means necessary, code reviews, replacing unsafe APIs like OpenBSD did replacing all occurences of strcpy(), strcat(3) and sprintf(3) by safer counterparts) and having tight memory protection. Add to that some privilege separation work, chroot(2) anything chrootable and you have way better sleep...
dooood sumtimes bean called a 14 year old is a steep up... it should be +1 !!!! Ha Ha Ha I just pooped my diapers!
AMD's big problem isn't marketing, it's manufacturing. AMD is doing a pretty good job with the resources they have, but Intel has much larger capacity. Nobody fabs like Intel, and nobody has fabs like Intel. So if AMD had more orders, they'd just have bigger backlogs. They may be able to get some third-party fabrication, like from IBM, but Intel would not let its fabs sit idle. I prefer AMD chips myself, at least for desktop-type applications (Intel still wins on mobile chips), but this is not like OS/2 (which I also preferred in its heyday) -- chipmaking is expensive!
It's not always possible to execute a return-into-libc attack. What if the function you want to jump to has a NULL byte in its address? In that case, you can't pass that address as part of a C-string. Patches exist to ensure that all functions in libc end in 00 to protect against return-into-libc attacks. For those interested in more details, Horizon's paper on bypassing no-exec stacks on Solaris explains the return-into-libc attack.
There are also cases where you don't need to insert code into an application. Instead, you can change the return value of a function or the outcome of a conditional security test to exploit the overflow. In such situations, you can achieve your goal by overwriting a variable without injecting code.
If the stack is protected and the heap is not, you can use a heap overflow to inject code into the heap, then use a stack overflow to corrupt the return address to point to the exploit code located in the heap. However, if the heap is non-executable too, this class of attack won't work.
Comment removed based on user account deletion
Didn't IBM systems 360 and 370 seperate memory sections for data and executable code ?
http://www.iamsam.com
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!
Not bad, but it's hard to beat: "Intel inside, idiot outside."
c++;
I think the posting summed it up neatly when it said "The question will be whether their PR department can spin this into a big enough story to sell to the Average Joe."
The Average Joe doesn't know what a buffer overflow is and he doesn't care. When you think about it... really, how many buffer overflow problems does Average Joe encounter? Yes, they're a plague to sysadmins, but for the regular guy who just wants to play EverQuest and surf the web it's not an issue. He isn't going to leap up and say "This is the solution to my problems!" He's more likely to frown at the phrase, scratch his head, mutter "Huh... I don't want to pay extra for something I'm not going to use," and go on his way.
So, this will never see adoption outside of a niche market for servers. AMD will not see a profit because of it, and I'd go so far as to wager they know that. I expect they're not going to spend all that much money in any marketing attempts.
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.
First of all.. virus protection has been in bios software way before the CiH virus, hell i think my 486 had it back in 1993... as for the buffer overflow protection.. read the damn article.. a buffer overflow is a buffer overflow.. this new chip prevents it by keeping the instruction area seperate from the data area.. there will be no buffer overflows period
That previous years haven't been filled with sloppy coding.
Actually I am part of the enterprise architecture that sets the standards for the company and reviews all projects going on in the bank, so yes I know where our infrastructure and systems are at and where we are going.
Right now we are in the middle of developing our plan for migration to linux. Yes we are planning on ending up with most of that 85,000 as linux desktops over the next 5 years.
Are large organizations slow? hell yes. but does that mean that they wont move to address risk and reduce expenses? hell no.
Except you are thinking of Alan Turing, not John Von-Neuman. Now, what I picture is Jerry Seinfeld as Eccard or Machley (sorr, sp??) working on the Eniac and saying in frustration:
"Von Neuman!!!"
JET Program: see Japan, meet intere
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.
The software has to be compiled to take advantage of this (hence the new version of XP)
actually, it only has to work in 64-bit mode in most of the cases. That is because by default heap allocs request the pages to have PROT_READ, which on x86-32 gives PROT_EXEC as well - not so in AMD64 64-bit mode. so for instance unless explicitly unset in the kernel boot parameters, AMD64 Linux kernels give buffer overflow protection for 32-bit apps, no recompile needed
of course, in windows world you need to wait for the 64-bit kernel, hence the new version of XP.
...that most of the software that experiences buffer-overflow problems is software that wasn't written using standard APIs (unless, of course, the standard APIs are buggy...). If they didn't do it right the first time, what makes you think they're going to re-write it in a less lazy form just because hardware supports it? Programmers could easily prevent buffer-overflows in software but they (sometimes) don't. If this is to work at all, it should probably be automatic. How to actually acomplish that is another question...
What is really needed is for compilers to have the option to include runtime overflow checking. I know it was decided to leave such a thing out of the ANSI C/C++ standards for speed/optimization reasons, but now it's causing quite a few headaches as we see that the more people we have programming, the less the ratio of careful programmers to non-careful programmers there are. Computers are faster these days, and perhaps the speed hit would be negligible.
Of course, adding such functionality in hardware would most likely keep such a problem to a minimum, but that leads us back to the first problem of detecting and/or APIs. Perhaps compilers will be modified as well as hardware?
CAn'T CompreHend SARcaSm?
...page-level non-executable flags?
Remember that no execute areas of memory, whule a good idea and preventitive of certian problems, do not even come close to preventing all ways of hacking a computer. If someone runs a malicious program, well it will execute since it was run. Ditto if a script kiddie breaks a weak password and installs a program.
So some moron (or more likey MANY morons) would get the AMD chip, think they were invincible, get hacked 6 ways from Sunday, and then sue AMD for false advertising. Worse? They might actually win.
AMD does not need that sort of shit, as it could be all it took for Intel to regain a total strangelhold.
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.
Basicly a lot of secuity problems will not work any more. Now this need to be expanded a bit more. Buffer alloc function (direct malloc direct realloc and direct free.) These in the kernel will detect buffer overflows allowing safe realloc of data or temination of program.
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
Pentium 4 seems to score better on all the benchmarks. I won't argue that the instruction set is butt ugly, but right now Pentium 4 is the fastest CPU in town... and, if you want all out elegance, you really can't top IBM's Power PC. It has all the registers you could ever want, easy 32 to 64 bit transition, simplified instruction set.. it's an assembler programmer's processor.
What's AMD have? Something in the middle... looks ugly like Intel, but not as fast.
This is my sig.
Sure, you can complain about their processors being beaten by AMD's when running at the same clock, but the manufacturing quality of Intel processors is very high.
The Raven
Anyone think HP will come out with an intellectual property noise ?
Cooperative multitasking is only better than preemptive if your only concern is that a process uses the minimum amount of CPU time possible.
I don't care if my MP3 player decodes 1 second of audio in 90 ms instead of 100 ms. All I care is that it gets the 100 ms it needs every second.
Likewise, I don't care if we can shave 1 ms off the time necessary for the CPU to handle me clicking a button. I just care that the UI responds immediately.
Yes, I realize that real-time scheduling would be even better for the things I just said. But that's got its own set of problems. Preemptive multitasking is a compromise between different needs that works really work most of the time.
IIRC, Celerons were basically Pentiums without the cache, so Celerons would not experience the cache-miss issues caused by self-modifying code, but I could be wrong...
>Eventually, I switched away from doing this to use 32-bit registered to behave like 2 16-bit registered to avoid doing lots of pushes. Just had to do rol 16 at appropriate times.
Thanks to the convolutedness of the x86 architecture, if you're running the CPU in 32-bit protected mode, you would have to add a prefix to each instruction to turn it into a 16-bit instruction. Not only does the prefix make the code longer, but this prefix also stalls the CPU. On 80486's and above, there's a bswap instruction (can't remember the exact name). This swaps the endian-ness of the dword in the register. bswap could be used instead of rol 16, and again instead of doing a ror 16 to get the value back. The only difference is that the bytes in the high-word of the dword will have their endian-ness changed, but if you're only doing this to shove a 16-bit value aside while you work on another 16-bit value, this should be no problem.
>I'm sort of surprised there isn't a compiler optimization to do this, as the results were nearly as fast as self-modifying code.
x86 assembler is a complete mess, and with somany processors and cache-configurations available - each with their own quirks, writing the most optimised code has become an artform and is something best done by hand. Of course, caches, virtual memory, multi-tasking and multi-processors make life that bit harder. If a C compiler was written that knew of the trick you mentioned, it would have to be able to tell which integers are 32-bits and which ones are 16-bits (when programming for an x86 architecture in C, it is adviasble to use 32-bit integers wherever possible regardless of the range of values it will store (except for when size is an issue). This is because there is no instruction-prefix for 32-bit instructions). The compiler has no means of knowing at compile-time whether or not a 32-bit integer is going to store values outside of the range of a 16-bit value, so it would not be able to apply this trick. If the programmer were to specify which values are 16-bit when writing the C code, they have no way of knowing if the compiler is going to use that particular trick or not, or if it would have come up with something faster if the values were 32-bit. And if you're that inclined to try and give hints to the compiler, you may as well be programming in assembly. So this optimisation is best left to writing assembly code by hand. However in C99, it is possible to specify that a data-type should be the fastest type that can store N bits (ie. not necessarily the smallest type), so a C99 compiler might just be able to handle that optimisation without the programmer giving hints to the compiler.
> IIRC, Celerons were basically Pentiums without the cache
The first Celerons were Pentium IIs with half the cache but at full speed (which ironically ended up making the Celerons faster than the Pentium IIs). Then Pentium IIs cache went full speed, so the Celerons became slower again.
> Thanks to the convolutedness of the x86 architecture, if you're running the CPU in 32-bit protected mode
The program is 16-bit DOS.
The bswap idea sounds good, but I'd rather if the program worked on all i386+ chips.
> If a C compiler was written that knew of the trick you mentioned, it would have to be able to tell which integers are 32-bits and which ones are 16-bits
No, that's not really necessary. Shorts are 16-bit integers. The idea really could be extended on Athlon 64's to make all the 64-bit registers behave like twice as many 32-bit registers, as I believe ints are still 32-bit on the Athlon 64. In any case, it'd be a nice hack to avoid the stack a little bit. I'm not sure how much of an improvement it'd really be, though.
Eurohacker European paranoia, gun rights, and h
The stock linux kernels support it already. Not sure if the 64-bit distro versions have it turned on by default (don't have the hardware to use it on).
--
Given enough personal experience, all stereotypes are shallow.
It is too out. Demo beta, yes, but all the functionality is there. Go look on filemirrors for xpsp2. heh.
~Fus
And if you are at all concerned about the security of your box you should take a look at SE Linux
Every time I go grocery shopping at the local Food Lion, I hear the Intel jingle played every 5 minutes mixed in with the ambient obligatory background music. That's Pretty scary if you ask me.
Fortunately, my Jedi mind powers are strong, and I can resist such subliminal messages!
For a nice date: call strftime(3C)
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.
Actually the first celerons didn't have L2 cache at all which gave the processor a really bad reputation. It was only later that intel came to their senses.
I stand corrected. I forget, the first Celeron (266) had no L2 cache. They overcompensated with the 300A. Well, anyways... :)
Eurohacker European paranoia, gun rights, and h
Start by rewriting bind in the safe language of your choice...
In the meantime, people are working at making current code that people are relying on more secure...
Until you have something to show, STFU...
AmigaBasic was written by Microsoft and one of the only programs I recall not working when the operating system was upgraded to V2.0.
Rarely the level of features and performances that people are used too... Find me something with the level of functionality of bind and that scale, i'm interrested...
I'm all for fixing the roots of the problem but it takes time and before it's ready some simple things can plug numerous holes...
AMD needs THIS!
Suggestion: Do a 'Google-image-search' for the term- "Intel Outside"; as used by many proud to not use Intel!
'Results 1 - 20 of about 199. Search took 0.18 seconds'
.
(David Bowman, EVA near HUGE Monolithic Win-PC in orbit around Jupiter) "My God - its full of Malware!"
Sorry, but we tried going all AMD in-house, and the machines were woefully instable at any speed. It's really sad, but true. I *wanted* to like AMD more, but any machine we've bought within the last 8 months has been Intel. We just can't afford the random downtime and reboots that only happen on AMD boxes.
The P4's and Xeons that have replaced them? Not one complaint.
i wish there was a '6' rating for genius comments.
this man/woman is informed and, most importantly, is extremely funny.
Ha ha ha.
When I buy a new system, I go by set budget. My last two systems havent been using AMD cpu to get same performance for less, but because I can get MORE performance for the same money.
After a 2 minuite check, if my budget allowed a 2.6ghz Intel and a fully featured motherboard, the AMD alternative for same price is a 3200XP with deluxe nforce2 - plus quality aftermarket HSF.
Comparing an intel's ghz CPU with the same PR AMD only makes sense to compare the two companies' marketing measures. Why anyone gives a shit about this is beyond me, and you only need to look within Intel's products to see mhz is just as much BS as PR - just compare Celeron, P4, P-m and P4EE.
Seriously. I know it would suck in many ways to have some legacy programs break, but sometimes those are the breaks.
In other areas of society, when we find problems that can easily be exploited we fix those issues, why don't we do that with computer science as well?
Keeping gets() around is akin to police departments issuing police cruisers with two doors, no partitions between the officer(s) and the person(s) riding in the back seat. That was stopped in the 70's from my understanding, when it was discovered that you really couldn't trust a number of the people riding in the back seat of a police cruiser.
I say break the old applications and bring some application of logic to computer programming for a change.
If you ignore the other uses of a tool, does that make the tool less useful, or you less useful?
>[...]
>> If a C compiler was written that knew of the trick you mentioned, it would have to be able to tell which integers are 32-bits and which ones are 16-bits
>No, that's not really necessary. Shorts are 16-bit integers.
Oops - I assumed you were writing 32-bit protected mode code. My bad.
>The bswap idea sounds good, but I'd rather if the program worked on all i386+ chips.
Now that I think about it, the bswap idea may not be such a good idea after all. IIRC, on 80486's and above, there is an execution pipeline that executes instructions while others further back in the pipeline are being decoded. For some reason, an opcode with less than two operands creates a stall (although I'm not so sure about 1 operand opcodes - it's been a while...). I'm not sure if bswap is one of those operands, but I remember one trick for optimising pairs of nop's that are used for padding is to replace two nop's with a mov eax, eax. This prevents a pipeline stall, and even decreases pipeline congestion, as this is a single instruction, and not two. So basically, you're getting the processor to do nothing faster. Even GCC uses that trick to generate faster code.
Why Didn't you write your own OS in a safer language of your choice other than C/C++?
Stop relying on "C weenies'" OS. Until you do, resorting to ad hominems won't improve security.
How does a C Software programmer influence flawed Hardware CPU designs? More desperate attempts at ad hominems, I see.