Are Hammer processors having a problem with Windows XP SP2, particularly when the NX feature is turned on?
Well, yes, but it’s important to understand why.
The NX feature in Hammers (and eventually Intel processors, too) is supposed to stop nasty things like viruses from doing certain kinds of things using unorthodox programming.
The immediate problem is that at least one legitimate program does the same thing (the program in question is the Sigma Designs Hollywood Plus DVD decoder).
Microsoft provides instructions for resolution at the abovementioned link (though we would suggest you try these BEFORE you reboot after SP2 installation).
Essentially, the folks who make this equipment need to rewrite the driver.
It’s unknown whether any other legitimate application does the same thing, but I suspect we’ll find out soon enough.
A Dubious Defense
What is also unknown is precisely why an NX flag-capable machine repeatedly reboots when this driver goes into action.
Well, we know why, the NX feature stop the driver from putting code in the wrong place. But does that mean that any program which tries to do something naughty is going to do the same thing to the machine?
If you look at some MS technical documentation, that would seem to be the case at least sometimes.
The primary benefit of data execution prevention is that it helps to prevent code execution from data pages such as the default heap, various stacks and memory pools. In normal operations of the system, code is not typically executed from the default heap and stack. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. If the exception is unhandled, the process will be terminated. Execution of code from protected memory in kernel mode results in a bugcheck.
This seems to say that if some program executes codes from protected memory in kernel mode, the machine will crash.
In other words, this essentially says to the virus-writers of the world, “Don’t do this or I’ll kill myself.” This is hardly going to deter such people; it’s more like a “Kick me” sign. With instructions.
The programmers of MS appear to be vaguely uneasy about this, because they go on to say:
“Although terminating a process or causing the system to fail with a bugcheck do not appear to be ideal experiences, this helps prevent malicious code from executing. Preventing malicious code from executing on the system may prevent damage to your system or propagation of malicious code whose harmful effects could easily exceed those of a process terminated by a bugcheck.”
This explanation could well be acceptable to a system administrator. Give that explanation to a room full of typical Joe Sixpacks who can handle the common cold better than a computer virus, and odds are the explainer will have his or her processes terminated, permanently.
To Joe Sixpack, spreading a virus is no big deal. Having a virus making his computer sick is, but running (or having someone else eventually run) a virus program isn’t too traumatic.
If the “cure” to the latter, though, is a “broken” machine with problems he can’t easily fix or even identify, he’d prefer the disease, thank you.
I think we have a problem here. Or, if we don’t, we need a really good explanation as to why we don’t or won’t have a problem with virus-writers targeting what looks to be a serious vulnerability.
And soon.
Be the first to comment