February 1998

One of the latest Intel Pentium bugs to come to light has been the "F00F" bug. Only Pentium processors, Pentiums with MMX, Pentium OverDrive processors, and Pentium OverDrives with MMX are affected by the bug. Pentium Pro processors, Pentium IIs, and i486 and earlier processors are not affected.        The bug is an invalid operation, and there are eight possible invalid instruction sequences. Say there's a byte sequence of "F0 0F C7 C8", which evaluates to LOCK CMPXCHG8B EAX.        According to Intel documentation, the CMPXCHG8B instruction, opcode "0FC7" in the byte sequence, compares an 8-byte value in EDX and EAX with an 8-byte value in memory (the destination operand). Memory operands are the only valid destination operands. If you attempt instead to use a register as the destination operand (like C8 in the instruction sequence above, which signifies the EAX register), the processor should generate an invalid opcode exception, stop the processing of the compare, and pass control to the invalid opcode exception handler. Since the Pentium's other registers (EBX, ECX, EDX, ESI, EDI, ESP, and EBP) can also generate the exception, there are eight versions of the invalid instruction sequence.        The problem occurs with the introduction of the LOCK prefix, "F0", to the instruction. The LOCK prefix locks the bus so that the following operation is made atomic—preventing perhaps another CPU from modifying the same memory location. We now have the makings of a classic deadlock situation. The LOCK of the bus occurs. Next the CPU attends to the CMPXCHG8B instruction, which is using in this case an invalid destination operand, EAX. OK, let's pass control to the invalid opcode exception handler. Oops! Since we need to get to the bus to get to the code for the handler, we're going to be staring at that hourglass till El Niño freezes over.        Since this is a bug in the chip itself, the code is not virulent only in privileged mode. It could live inside an ActiveX control in a Web browser running at user privilege or a CGI script on a Web server—either would freeze the box it was running on immediately.        Intel says that the good news is that no memory data is corrupted, but the bad news is that your only option is to power down. Don't panic. Intel has offered several workarounds intended for OS manufacturers. Microsoft has provided a hotfix for this bug for Windows NT 4.0. For more information, see ftp://ftp.microsoft.com/bussys/winnt/winnt- public/fixes/usa/NT40/hotfixes-postSP3/pent-fix/. The fix has not been fully regression-tested and should be applied only to systems experiencing this specific problem. Unless you're severely affected by this problem, we recommend that you wait for the next Service Pack that contains this fix.        What about Windows 95, Windows 3.1, and Windows NT 3.5x? Microsoft is still making a determination about how to address this bug in all the other Windows operating systems.        Has all this Intel assembly-speak whetted your appetite for more? Whether you've never dealt with assembly before (say it ain't so, Hanson listeners) or need that refresher course, check out Matt Pietrek's handy assembly language survival guide in this month's "Under the Hood" column. — J.F. From the February 1998 issue of Microsoft Systems Journal