views:

596

answers:

6

A friend sent me that code and alleges that it could damage the processor. Is that true?

void damage_processor() {
    while (true) {
        // Assembly code that sets the five control registers bits to ones which causes a bunch of exceptions in the system and then damages the processor
        Asm(
            "mov cr0, 0xffffffff \n\t"
            "mov cr1, 0xffffffff \n\t"
            "mov cr2, 0xffffffff \n\t"
            "mov cr3, 0xffffffff \n\t"
            "mov cr4, 0xffffffff \n\t"
        )
    }
}

Is that true?

+13  A: 

Maybe if you let it run for about 20 years.

Serapth
+7  A: 

Maybe this code causes your processor/system to lock up but there is no chance that it damages it permanently.

Imagine if this were true: it would immediately be used by viruses/trojans to attack computers or hide their activity after detection.

Even in the case that any code could damage a processor, the processor manufacturer could issue a so called microcode-update which is something like a soft-fix for the processor. Such microcode-updates are provided by operating systems and/or BIOS (and processor manufacturers) and are loaded into the processor before such code could be executed.

To sum it up: No, your friend is wrong, assuming we're talking about x86/x64 platforms.

Kosi2801
+5  A: 

No. If the point is to feverishly excercise the processor in hopes of breaking it, computer systems have thermal solutions (fans, copper heat exchangers, heat sinks, etc.) to prevent overheating. In the event of a failure in the thermal solution, the BIOS will assert #THERMTRIP and turn off the machine.

William Leara
+1  A: 

I heard rumor of a bug in the Pentium I that when given a certain nonsensical series of instructions in a tight loop would burn up a single flip-flop so fast the thermal protection couldn't protect it.

What I found reference for once was really old CPUs could be cooked by doing this in real mode:

halt:
    jmp short halt

The correct code was

halt:
    nop
    jmp short halt
Joshua
Could you also provide the reference to us?
Kosi2801
I sincerely doubt that. AFAIK Pentium 1 had no thermal protection. Additionally, any Intel-approved heatsink would be more than sufficient to keep the core temp in check even with the max power draw. http://www.intel.com/design/pentium/datashts/24199710.pdf
msemack
+11  A: 

From userspace code? No. It'll cause a privilege exception and the kernel will terminate your program. From kernel code? I doubt it; you will be throwing exceptions, and you'd have to manually set up the fault handler to return to the code in question to keep doing it. There's also a decent chance you'll cause a triple fault if part of the CR3 move succeeds, since that controls the page table address and you'll probably get faults on instruction fetch, handler fetch, and then the double fault handler fetch. The CPU should just shut down if that happens.

Check the Intel or AMD manuals for Systems programming, they'll tell you which exceptions will be thrown when writing invalid bits to the control registers.

Ivatar
Triple faults usually trigger a reboot.
msemack
The double fault handler fetch should come from a task gate anyway, with a "safe" CR3 value for the CPU to load along with safe stacks and register values. Smashing CR3 "shouldn't" triple-fault the system (theoretically), but it's still not a good idea.
Matthew Iselin
+1  A: 

Sorry, the code doesn't run on an ARM processor.

In many processors, instructions that set the status word or affect the processor are restricted to "supervisor" mode. Good operating systems run User code in a "protected" mode that does not have the same capabilities as "supervisor" mode. Executing privileged instructions on modern processors in User mode generates exceptions.

You and your friend could always look up the instructions in an assembly language reference manual and verify the operation.

Thomas Matthews
this code was for Pentium 4 btw
Radian