Forgive me if my memory fails me.
The important thing to know here is that CMPXCHG8B compares the 64-bit
value in the concatenated registers EDX:EAX with the operand (ostensibly
a 64-bit datum in memory).
The deal with the 0F 0F C7 C8 is that the last byte, C8, is a part of
the instruction called the MOD R/M byte. This byte is composed of
three fields; Mod, Reg/Opcode, and R/M. The Opcode field, bits 3-5,
is used up by the instruction in this case, giving it a fixed value of
"001". The Mod (bits 6-7) and R/M field (bits 0-2) combine to form
an addressing mode which specifies the register EAX. Since the
comparison is supposed to occur over 8 memory bytes, this is obviously
not a valid instruction.
Combining CMPXCHG8B with LOCK is okay; LOCK asserts the LOCK# pin,
guaranteeing exclusive use of the memory bus during the instruction.
This is mostly useful on multiple-processor machines.
It is the opinion of an anonymous source at an Austin-based processor
manufacturer that the Intel hardware designers forgot to unlock the
bus before trying to load the descriptor for the appropriate
exception handler, which would explain why locking it into the
L1 cache helps. I suppose the hardware does unlock it before actually
executing the handler. It is unclear to me why completely disabling the
L1 cache in the BIOS is rumored to help.
This really belongs on an Intel hardware list and not on bugtraq,
but I think since we repeated several fact shreds here, it merits
a more complete explanation.
Sorry to prolong this already tedious thread.
I wonder if anyone has taken the obvious (but somewhat laborious)
task of attempting an exhaustive test of invalid instructions with
a LOCK prefix.
It has been said that the bug might have been discovered by an Intel
competitor, implying that they wanted to damage Intel. Posting to
Linux newsgroups would be an unnecessarily indirect method of doing that.
I find it equally possible that it could have been someone simply
experimenting with an assembler, or who happened to execute a mangled
binary and had the tenacity to track down the bug. I wouldn't blame
anyone for not signing their name to a bug potentially as serious as
this one, and remaining anonymous shows remarkable ego control.
After all, you never know who your next employer will be :)
-- VaX#n8