AMD Could Profit from Buffer-Overflow Protection

← Back to Stories (view on slashdot.org)

AMD Could Profit from Buffer-Overflow Protection

Posted by ryuzaki0 on Monday February 23, 2004 @07:31AM from the brimming-moneybags dept.

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."

15 of 631 comments (clear)

Min score:

Reason:

Sort:

Code rewrites going to be needed? by PornMaster · 2004-02-23 07:33 · Score: 5, Interesting

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
1. Re:Code rewrites going to be needed? by chamilto0516 · 2004-02-23 07:40 · Score: 5, Interesting
  
  Self modifying code apps would be affected. And I think that is a good thing because you would want to ferret out such things in your systems.
  Writing self-modifying code was the first thing my Assembler instructor put his foot down and said, "bad idea, don't even think about it." I could see you could do it easily with assembler.
  I would entertain listening to cases where self-mod'ing code has its place.
  
  --
  Magic Eight Ball: Outlook not so good., Hmmm, how about Excel and Word?
2. Re:Code rewrites going to be needed? by J-Worthington · 2004-02-23 07:50 · Score: 4, Interesting
  
  One type of application that would need to take this into account would be JIT compilers, e.g. like that used in .Net. These create native code in memory to execute, with the objective of increasing performance. These apps simply need to state that they want the memory they allocate to be executable when they allocate it, then they can continue to work as before.
3. Re:Code rewrites going to be needed? by imnoteddy · 2004-02-23 07:51 · Score: 4, Interesting
  
  My guess is that many applications use self-modifying code as part of their anti-piracy/anti-reverse-engineering protection.
  In the early '90s Motorola released the 68040 with a code cache that made programs that used self-modifying code crash and burn. Apple had been telling people for years not to write self-modifying code because this was going to happen. When Apple started building prototype Macs with 68040s and started testing for compatibility who do you suppose was one of the biggest offenders? Microsoft. I am not making this up.
  
  --
  No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
4. Re:Code rewrites going to be needed? by larkost · 2004-02-23 08:35 · Score: 4, Interesting
  
  On Apple platforms Microsoft has a very long history of this. There was another major case in the Apple II era where Apple developer documentation specifically reserved an address space for future expansion. Microsoft ignored this, and the IIe broke a good chunk of their software because of this.
  
  Microsoft has historically had very bad coding practices. From all accounts I have heard this has markedly improved, but it was pretty bad.
Nope by lukewarmfusion · 2004-02-23 07:37 · Score: 4, Interesting

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).
1. Re:Nope by Inuchance · 2004-02-23 08:04 · Score: 5, Interesting
  
  I think a good commercial would having hackers trying to break into a computer, and then a big "ACCESS DENIED" error shows, and one of the hackers exclaims, "No good, they've got the latest AMD CPU!" And then some announcer says something like, "With the latest CPUs from AMD, your computer executes only what YOU want it to, not what THEY [flash over to image of frustrated hackers] want!"
Re:Pathetic by strictnein · 2004-02-23 07:44 · Score: 5, Interesting

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
Old news by Todd+Knarr · 2004-02-23 07:47 · Score: 5, Interesting

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.
Execution bit on MMU Pages by adisakp · 2004-02-23 07:49 · Score: 5, Interesting

For what it's worth... many processors, like the PowerPC series have had this "buffer overflow protection" feature for years. The idea is to mark program code pages after they are loaded as executeable and read-only. No other pages are marked executeable. It destroys clever little hacks like self-modifying code but at the same time, makes it impossible for buffer overflows to introduce new code into a programs executeable code page set.
The Average Joe? by SpaceRook · 2004-02-23 07:50 · Score: 5, Interesting

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.
Re:AMD needs better marketing by Neil+Watson · 2004-02-23 08:02 · Score: 5, Interesting

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
stupid by ajagci · 2004-02-23 09:10 · Score: 4, Interesting

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.
Re:Linux support by Tony+Hoyle · 2004-02-23 09:19 · Score: 5, Interesting

It's been implemented in Linux since about 6 months ago, at least on the amd64 branch.

http://www.x86-64.org/lists/discuss/msg03469.htm l
Re:AMD needs better marketing by Krondor · 2004-02-23 09:43 · Score: 4, Interesting

PCI Locking and more specifically.