Bugtraq mailing list archives
mode of the i586 F0 bug
From: vax () LINKDEAD PARANOIA COM (VaX#n8)
Date: Wed, 12 Nov 1997 15:19:34 -0600
I believe the instruction in assembler would be: LOCK CMPXCHG8B EAX 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
Current thread:
- Possible solution: [Fwd: I figured out how to make my Pentium, (continued)
- Possible solution: [Fwd: I figured out how to make my Pentium Miguel Angel Rodriguez Jodar (Nov 10)
- Re: Intel Pentium Bug Tim Newsham (Nov 10)
- CERT Advisory CA-97.25 - CGI_metachar Aleph One (Nov 10)
- Re: CERT Advisory CA-97.25 - CGI_metachar Greg Bacon (Nov 11)
- L0pht Advisory: IE4.0 DilDog (Nov 10)
- L0pht Advisory: IE4.0 Petri Helenius (Nov 10)
- Cisco IOS password encryption facts John Bashinski (Nov 10)
- Re: Cisco IOS password encryption facts ice9 (Nov 11)
- Re: Cisco IOS password encryption facts J. Sean Connell (Nov 11)
- Re: Cisco IOS password encryption facts Michael Degerman (Nov 13)
- mode of the i586 F0 bug VaX#n8 (Nov 12)
- Re: mode of the i586 F0 bug Alan Cox (Nov 12)
- Linux F00F Patch Aleph One (Nov 12)
- Re: Safe /tmp cleanup Randal Schwartz (Nov 12)
- Re: Safe /tmp cleanup dsiebert () ICAEN UIOWA EDU (Nov 13)
- another buffer overrun in sperl5.003 Pavel Kankovsky (Nov 13)
- Re: Safe /tmp cleanup Valdis Kletnieks (Nov 13)
- IE4.0 patch Richard Trott (Nov 13)
- X Security problem (?) Carlo Wood (Nov 13)
- Re: X Security problem (?) Matthias Buelow (Nov 14)
- Re: X Security problem (?) Scott Moseman (Nov 14)