Comments on: Microsoft tackles AMD conflict in SP2
Microsoft says SP2 may not work on computers powered by chipmaker's 64-bit processors under certain circumstances.
Microsoft says SP2 may not work on computers powered by chipmaker's 64-bit processors under certain circumstances.
December 5, 2009 4:54 PM PST
December 5, 2009 2:35 PM PST
December 5, 2009 1:11 PM PST
Add headlines from CNET News to your homepage or feedreader.
More feeds available in our RSS feed index.
Related quotes
This article is terribly misleading. Tsk tsk! I ask the author of the article, do you have agenda regarding SP2, or don't you understand the Knowledge Base article?
Anyone who reads the actual knowledge base article will note that the flaw only occurs in a very specific software package.
The fact that it affects only AMD's 64-bit processor is because Intel's don't feature the NX flag.
Yet the title of the article clearly insinuates otherwise. Even the subtitle doesn't mention the fact that it's due to a third party software flaw and is totally unrelated to AMD's line of 64 bit processors.
The more articles like this I encouter, the more I begin question the accuracy of other news brought by cnet.
When your reports on SP2 are so biased to being downright untrue, I am quickly loosing confidence in your ability to accuratly report ICT news.
XP SP2 contains a new feature called Data Execution Prevention, usually called NX for short ("no-execute"). It requires all of memory to be marked as either "code pages" (which contain only executable programs) or "data pages" (which contain everything else.) This helps alleviate the problem of buffer overflows, where a hacker injects specially crafted data containing program code into a running program, causing it to execute the hacker's code instead of the program's own. What Data Execution Prevention does is place an extra restriction on execution -- if at any point the CPU is instructed to execute code in a data page, it throws an access violation (which generally crashes the offending program.) Thus, if your hacker tries to use a buffer overflow, he successfully writes his malicious code into memory, but he's written it to a data page -- and thus when he tries to run his code, instead of it doing what he wants, all it does is crash the program he's exploiting. Thus, a root-compromise security hole (allowing the hacker to take control of the system, steal data, format the hard drive, or whatever) becomes only a denial-of-service (allowing the hacker to crash a single app.) This is a good feature.
However, the feature requires support from the CPU, allowing pages to be marked as code or data. And currently, the only CPU that has this support is the AMD Athlon64. In a few months, all the new Intel Pentium 4s will have it, too, as will AMD's new low-end Sempron chip. This is not a problem with AMD's chip -- it's just that people with AMD's chip are the only ones using this new feature yet!
Now, an app executing code on its data pages is a no-no. You're not supposed to do that. However, a few apps do, generally for copy-protection purposes (for instance, decrypting themselves into memory then running the decrypted code.) For those apps, Microsoft provides a simple way to exclude an application from Data Execution Prevention. For that matter, if you really want to, you could turn the feature off altogether, and be no worse off buffer-overflow-wise than you were in SP1, while still maintaining all of XP SP2's other great security features. Why someone at Microsoft suggested uninstalling SP2 to deal with this problem is a complete mystery to me -- just unsecure the one offending program, or even disable the one offending feature; don't roll back the entire security upgrade!
The particular problem here is that apparently Sigma Designs' Realmagic Hollywood Plus DVD Decoder does do the trick of executing its own data pages on purpose. Thus, Data Execution Prevention falsely identifies it as an attack and crashes the program. The unfortunate part is that rather than running as an application like everything else, Realmagic runs as a device driver (which is why it has a filename ending in .sys). Device drivers run privileged at Ring 0, in kernel mode. If Data Execution Prevention killed off a normal application, it would just crash the application -- no big deal. But crashing something that runs in kernel mode results in a lovely blue screen that says "STOP 0x0000001E: KMODE_EXCEPTION_NOT_HANDLED." Not a good user experience by any means.
The lessons here are not, as the press seems to think, "There is a bug in XP SP2" or "XP SP2 is incompatible with AMD Athlon64 processors." No, there are two lessons here, and they're both for software developers:
1.) Don't try to execute data pages. In a few months, everybody will have this feature and nobody will be able to run your app. Lay off the copy protection a bit and just write normal applications.
2.) For crying out loud, don't run in kernel mode! If there is any way whatsoever to do what you want to do in user mode, do not under any circumstances run anything in kernel. Running in kernel means that if you do anything wrong anywhere, you bring down the entire system. This is a risk you do not need.
The Microsoft of three years ago wouldn't have included this feature, because it "breaks application compatibility." The Microsoft of today is not so foolish; security trumps application compatibility now, and application developers will need to get used to thinking about security as well.
AMD designed the AMD64 with the NX instruction and collaborated with Microsoft to incorporate this feature in SP2! So, everything is working EXACTLY as it is supposed to.
So, the author of this article, if he/she has any morals/integrity, should make this abunduntly clear to their readers and quit spreading malicious lies!!
Ken.
The problem is not with the AMD64 and SP2. They are functioning exactly as they were intended to by design.
You are mileading readers with you stupid, irresponsible articles!!
- When is CNet going to Report Accurately???
- by R.T.F.M. August 30, 2004 4:49 AM PDT
- Why do you insist on perpetuating FUD?
- Like this Reply to this comment
-
(10 Comments)The problem is not with the AMD64 and SP2. They are functioning exactly as they were intended to by design.
You are mileading readers with your stupid, irresponsible articles!!