Cyrix coma bug
From Wikipedia, the free encyclopedia
The Cyrix coma bug is a design flaw in Cyrix 6x86, 6x86L, and early 6x86MX processors that allows a non-privileged program to completely lock the computer.
Contents |
[edit] Discovery
According to Andrew Balsa, around the time of the discovery of the f00f bug on Intel Pentium, Serguei Shtyliov of Moscow found a flaw in a Cyrix processor while developing an IDE disk driver in assembly language. Alexandr Konosevich, from Omsk, further researched the bug, and coauthored an article with Uwe Post in the German technology magazine, c't, calling it the "hidden CLI bug" (CLI is the instruction which disables interrupts in the x86 architecture). Balsa, as a member on the Linux-kernel mailing list, confirmed that the following C program could be compiled and run by an unprivileged user:
static unsigned char c[4] = {0x36, 0x78, 0x38, 0x36};
main()
{
asm ("movl $c, %ebx\n\t"
"again: xchgl (%ebx), %eax\n\t"
"movl %eax, %edx\n\t"
"jmp again\n\t");
}
Execution of this program renders the processor completely useless, as it enters an infinite loop that cannot be interrupted. This presents a security flaw because any user with access to a Cyrix system with this bug could prevent other users from using the system. Exploitation of this flaw would therefore be a denial-of-service attack. It is similar to execution of a Halt and Catch Fire instruction, although the coma bug is not any one particular instruction.
[edit] Analysis
What causes the bug is not an interrupt mask, nor are interrupts being explicitly disabled. Instead, an anomaly in the Cyrix's instruction pipeline prevents interrupts from being serviced for the duration of the loop; since the loop never ends, interrupts will never be serviced. The xchg[1] instruction is atomic, meaning that other instructions are not allowed to change the state of the system while it is executed. In order to ensure this atomicity, the designers at Cyrix made the xchg uninterruptible. However, because of pipelining and branch predicting, another xchg enters the pipeline before the previous one completes, leaving the processor in this uninterruptible state forever.
[edit] Workarounds
A simple fix is to insert another instruction in the loop, the nop instruction being a good candidate.
One way to prevent this bug is to enable bit 0x10 in the configuration register CCR1. Alternatively, Cyrix provided a way to fix this, by serializing the xchg opcode, thus bypassing the pipeline.
[edit] See also
[edit] Notes
[edit] External links
- Andrew Balsa's early description of the bug
- Cx6x86 registers (and undocumented features)
