This is the code reportedly will crash your Pentium machine: long main [] = { 0xc8c70ff0 }; :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Pentium bug surfaces By Brooke Crothers November 7, 1997, 2:20 p.m. PT A new bug that crashes Intel (INTC) Pentium processors has been found and is now being discussed openly on the Internet. The bug has the potential to crash Pentium computers and could be used for sabotage, according to Robert Collins, whose Intel Secrets Web site tracks inside information on Intel, the world's leading chipmaker. The Pentium "F0" or "F00F" bug can freeze up Pentium MMX and "classic" Pentium (non-MMX) computers, according to Collins. Worldwide, these machines number in the hundreds of millions. Intel engineers were meeting on Friday about the bug, according to sources. Message traffic concerning the bug is starting to pick up in Intel newsgroups on the Internet, just as it did for the Pentium FPU bug a few years ago. "This is for real. I've known about it for a couple of months," Collins said. "I actually think theres no excuse for [Intel] not having found this," he asserted. Collins added that he tried to contact Intel twice but received no response. "Who knows, maybe they think the [Pentium is] dead anyways, so why bother to worry about any more bugs?" he said. Intel says not so. "We've just found out about it today. We're looking into it," an Intel spokesman said. "We have no further comment at this time." Collins said he got the first response from Intel on the bug Friday. He said someone must have malicious intent for the bug to actually wreak havoc, making it different than past Pentium and Pentium Pro bugs. The bug apparently is a single illegal instruction and not something that would be deliberately coded into a software program, according to Collins. Therefore, it will not be found in commercial software or independently developed software. Nevertheless, this instruction could be maliciously inserted into a small C language program and used to bring down a companys server computers, according to Collins. For example, a person could dial into his Internet service provider), send the C program, and crash an Internet Service Provider's (ISP) server. But one ISP contacted said this is more a reflection of a common problem with computers than a specific Pentium glitch. "You'd have to have an account with the ISP or some access to machine. [But] if you've got some way in, or if you've got an account with the ISP, there are already far worse things you can do," said Bill Mattocks, proprietor of Computer Solutions, a small ISP in Kenosha, Wisconsin. The bug is not listed by Intel in its compilation of processor bugs or "errata" which it publicizes, according to Collins. But as is usually the case when a bug surfaces, there is some confusion. Some observers posting messages on the Intel Newsgroup on the Internet say that this is in fact a legal instruction. "This bug is not an illegal instruction problem, it is a documented instruction. A highly useful, but Pentium-and-above specific instruction, that should have been highly tested at some point in the production process," said Jim Bryant, a software programmer. On May 2 of this year, NEWS.COM first reported a different bug that affected Pentium Pro and Pentium II processors. One week later, Intel admitted that a glitch involving the conversion of "floating point" numbers to integer numbers could generate wrong answers in some cases and posted a work-around on its Web site. Intel is an investor in CNET: The Computer Network. -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- For those of you who have heard someone has found a new bug in the Pentium and are interested in learning more about it, read on. There is an article at http://www.news.com/News/Item/0,4,16173,00.html that talks some about this bug. No doubt there are many other references, and more being created hourly. A C program that hits it is: char illegal_op = { 0xf0, 0x0f, 0xc7, 0xc8 }; main() { void (*f)() = illegal_op; f(); /* No need for a return value, you ain't gettin' here. */ } I compiled the program and ran it on a 486, Pentium, and PPro box on Linux and Windoze NT. The Pentium locked up, and the other two "did the right thing." By locked up, I mean "stopped responding to interrupts, even the three figured salute (Cntrl-Alt-Del)". So this bug is almost certainly real. In fact, Intel probably thinks it's real because they summoned Anuj back to Santa Clara posthaste. It requires one instruction: f0 0f c7 c8 which is an almost legal instruction to compare and exchange 8 bytes. All four bytes are required, but no special privilege or operands in registers are necessary. The pseudo-code (paraphrased from the Pentium Programmers Manual) is: lock_bus if (edx:eax == dest) { zf <- 1 dest <- ecx:ebx } else { zf <- 0 edx:eax <- dest } unlock_bus For those not familiar with the way x86 works, here's what the instruction means. The first byte, f0, is optional and requests the processor to lock down the bus for the duration of this instruction. This makes this instruction atomic so all other processors accessing the location modified by this instruction will see either all or none of the result of this instruction. In x86, there are no address alignment restrictions, so the 8 bytes operated on could cross a cache line or otherwise be hard to get at in one cycle. (Other possible reasons are, for example, the [23]86, which didn't have caches.) Most people agree that the LOCK pin is not the most visionary design, but it seemed like a good idea in 1975. Frankly, I couldn't have come up with a better one because I was probably learning to finger paint at the time. In case you're wondering, Gunnison will have a LOCK pin. The second byte (0f) is the first part of the opcode, and specifies that this instruction is a two byte instruction. Most of the time the instruction opcode is specified in one byte. However, if the first opcode byte is 0f (or a few others), two bytes are required to figure out if this instruction is an add; branch; polynomial evaluate; or the ever popular "jump through a task gate, do a context switch, put on a multicolored bunny suit, and dance with the Rockettes." The third byte (c7) is the second byte of the opcode. At this point, the processor knows the major opcode, which is in the group of the CMPXCHG8B instruction. It turns out that CMPXCHG8B is the only valid subop for this major op. The fourth byte (c8) specifies the addressing mode, subop, and destination for the instruction. There are an exiciting variety of addressing modes available to x86 programs. The first two bits (11) specify that this is a register to register instruction. The second three (001) specify the subop. Opcode 0f c7, subop 001 is the CMPXCHG8B instruction. The third three (000) specify that register EAX is the target. Kind of. These bits are probably don't cares, because register to register addressing is not allowed for this instruction. The first and last bytes are the interesting ones here. The last byte specifies an addressing mode (register to register) that is illegal for this instruction. The Pentium manual says that the machine must take an undefined instruction trap (in protected and VM86 mode) if the addressing mode specifies a register destination. It doesn't say what to do in real mode, but "lock up the machine" is probably not one of the desired behaviors. This is probably because x86 only has 4 byte registers, and the instruction already uses the four normally used for data manipulation (the other four are typically used for address formation). A reasonable guess is that on Pentium, the processor locks down the bus, does something, then fails to unlock the bus. It's only a matter of time until you need to access the bus again (even if it's only to fetch in the trap handler), and it can't because it locked the bus down. Thanks for playing. It's also possible that the decoding PLAs throw this one on the floor and jumps off into a random point in the microcode ROM, and gets caught in a microcode loop. If this instruction is run without the LOCK prefix, the machine takes the trap specified, just like 486 and PPro. So the LOCK prefix is required, and it is almost certain that when combined with the illegal addressing mode it exposes the problem. The chances are that "what we've got here is...failure to communicate" between the LOCK state machine and the trap state machine. As for impact, this instruction is basically illegal. Most assemblers probably don't allow you to assemble it (since strictly speaking there is no mnemonic for it), and there is essentially no chance that compilers emit such a beast. So no program besides one written to hit this bug can hit this problem. Also, you have to be running on the machine to do anything, so access over the web is not sufficient to run this instruction, unless there is a gaping hole in your web server. Viruses could take advantage of this problem to deprive people of their machines (installing it in a boot file or somewhere in the code for a system call would make things not be cool). But this mostly affects people with running multi-user OS's, like Unix. Malicious User X can deprive all the other nice users of the machine just by executing this instruction. (Hear that, Intrigue users?) Windoze, while theoretically configurable as a multi-user networked OS, in practice is a password protected single user OS. It's possible that a user could ruin his or her ISP's day by having a cgi-bin script that locks up the machine when someone clicks on their web page. You could sneak over to somebody's desk and run this program, but that isn't very fun when you could walk over and cycle the power anyway. DOS...well, let's not even talk about DOS. Finally PPro (and probably Pentium II) machines trap the instruction as advertised. The Pentium Programmers Manual says clearly that register to register addressing mode traps, and mentions the possibility of and reason for using the LOCK prefix in the description for the instruction. This is pretty humiliating, roughly as bad as the FIST and FDIV bugs. For those of you terrified about things like this (I am), I'm fairly confident we would have caught this if it had slipped into Bifrost (the EIO-iVE on Gunnison). SuperG would probably have our heads on a platter if we let this one through. Unless of course, Paul French had SuperG's head on a platter first. In fairness to Intel, I'm don't know if our test generation capability was up to the task when Pentium was first shipped but things have come a long way in five years or so. They really should have caught this on the MMX Pentiums. This may be an exciting opportunity for Intel to show off their microcode patching capability, although it's not clear how patchable the Pentium microcode is. In fact, maybe Intel did know about this, since the PPro manual specifies explicitly that this instruction traps in real mode. It is pretty unusual for Intel to correct errors and/or update descriptions in their technical documentation---I can show you the same typos in 386, 486, Pentium, and PPro manuals. But if they did it seems unlikely that they would neither have published it as an errata (it doesn't matter much to regular users) or fixed it. --