Editing Pentium F00F bug

{{Short description|Pentium processor bug}}
{{Use dmy dates|date=June 2022|cs1-dates=y}}
{{Use list-defined references|date=June 2022}}
[[File:Intel_pentium_75mhz_p54.jpg | thumb | right | Intel Pentium processor]]
The '''Pentium F00F bug''' is a design flaw in the majority of [[Intel]] [[Pentium]], [[Pentium MMX]], and [[Pentium OverDrive]] [[microprocessor|processor]]s (all in the [[P5 (microarchitecture)|P5 microarchitecture]]). Discovered in 1997, it can result in the processor ceasing to function until the computer is physically rebooted. The [[hardware bug|bug]] has been circumvented through [[operating system]] updates.

The name is shorthand for <code>F0 0F C7 C8</code>, the [[hexadecimal]] encoding of one offending [[instruction (computer science)|instruction]].<ref name="Collins_1998"/> More formally, the bug is called the ''invalid operand with locked CMPXCHG8B instruction bug''.<ref name="Intel_1998_Update-cmpxchg8b"/>

==Description==
In the [[x86|x86 architecture]], the byte sequence <code>F0 0F C7 C8</code> represents the instruction <code>lock cmpxchg8b eax</code> (locked compare and exchange of 8 bytes in register EAX). The bug also applies to opcodes ending in <code>C9</code> through <code>CF</code>, which specify register [[Operand#Computer science|operands]] other than EAX. The <code>F0 0F C7 C8</code> instruction does not require any [[ring 0 (computer security)|special privileges]].

This instruction encoding is invalid. The <code>cmpxchg8b</code> instruction compares the value in the EDX and EAX [[processor register|registers]] with an 8-[[byte]] value in a memory location. In this case, however, a register is specified instead of a memory location, which is not allowed.

Under normal circumstances, this would simply result in an [[exception handling|exception]]; however, when used with the ''lock'' prefix (normally used to prevent two processors from interfering with the same memory location), the CPU erroneously uses locked bus cycles to read the illegal instruction exception-handler descriptor. Locked reads must be paired with locked writes, and the CPU's bus interface enforces this by forbidding other memory accesses until the corresponding writes occur. As none are forthcoming, after performing these bus cycles all CPU activity stops, and the CPU must be reset to recover.

Due to the proliferation of Intel microprocessors, the existence of this open-privilege instruction was considered a serious issue at the time. [[Operating system]] vendors responded by implementing [[workaround]]s that detected the condition and prevented the crash.<ref name="Torvalds"/> Information about the bug first appeared on the Internet on or around 8 November 1997.<ref name="Hovers_1997"/> Since the F00F bug has become common knowledge, the term is sometimes used to describe similar hardware design flaws such as the [[Cyrix coma bug]].

No permanent hardware damage results from executing the F00F instruction on a vulnerable system; it simply locks up until rebooted. However, [[data loss]] of unsaved data is likely if the [[page cache|disk buffers]] have not been flushed, if drives were [[interrupt|interrupted]] during a write operation, or if some other non-[[atomic operation]] was interrupted.

The B2 [[Stepping level|stepping]] solved this issue for Intel's Pentium processors.<ref name="Intel_1998_Update-cmpxchg8b"/>

The F00F instruction can be considered an example of a [[Halt and Catch Fire (computing)|Halt and Catch Fire]] (HCF) instruction.

==Workarounds==
Although a definite solution to this problem required some sort of hardware/firmware revision, there were proposed workarounds at the time<ref name="Collins_1998"/> which prevented the exploitation of this issue in generating a [[denial-of-service attack]] on the affected machine. All of them were based on forcefully breaking up the pattern of faulty bus accesses responsible for the processor hang. Intel's proposed (therefore "official") solutions required setting up the table of interrupt descriptors in an unnatural way that forced the processor to issue an intervening page fault before it could access the memory containing the descriptor for the undefined-opcode exception. These extraneous memory accesses turned out to be sufficient for the bus interface to let go of the locking requirement that was the root cause for the bug.

Specifically, the table of interrupt descriptors, which normally resides on a single memory page, is instead split over two pages such that the descriptors for the first seven exception handlers reside on a page, and the remainder of the table on the following page. The handler for the undefined opcode exception is then the last descriptor on the first page, while the handler for the page-fault exception resides on the second page. The first page can now be made not-present (usually signifying a page that has been swapped out to disk to make room for some other data), which will force the processor to fetch the descriptor for the page-fault exception handler. This descriptor, residing on the second page of the table, is present in memory as usual (if it were not, the processor would [[double fault|double]]- and then [[triple fault|triple-fault]], leading to a shutdown). These extra memory cycles override the memory locking requirement issued by the original illegal instruction (since faulting instructions are supposed to be able to be restarted after the exception handler returns). The handler for the page-fault exception has to be modified, however, to cope with the necessity of providing the missing page for the first half of the interrupt descriptor table, a task it is not usually required to perform.

The second official workaround from Intel proposed keeping all pages present in memory, but marking the first page read-only. Since the originating illegal instruction was supposed to issue a memory write cycle, this is enough for again forcing the intervention of the page-fault handler. This variant has the advantage that the modifications required to the page-fault handler are very minor compared to the ones required for the first variant; it basically just needs to redirect to the undefined-exception handler when appropriate. However, this variant requires that the operating system itself be prevented from writing to read-only pages (through the setting of a global processor flag), and not all kernels are designed this way; more recent kernels in fact are, since this is the same basic mechanism used for implementing [[copy-on-write]].

Additional workarounds other than the official ones from Intel have been proposed; in many cases these proved as effective and much easier to implement.<ref name="Collins_1998"/> The simplest one involved merely marking the page containing interrupt descriptors as non-cacheable. Again, the extra memory cycles that the processor was forced to go through to fetch data from RAM every time it needed to invoke an exception handler appeared to be all that was needed to prevent the processor from locking up. In this case, no modification whatsoever to any exception handler was required. And, although not strictly necessary, the same split of the interrupt descriptor table was performed in this case, with only the first page marked non-cacheable. This was for performance reasons, as the page containing most of the descriptors (and the ones more often required, in fact) could stay in cache.

For unknown reasons, these additional, unofficial workarounds were never endorsed by Intel. It might be that it was suspected that they might not work with all affected processor versions.

==See also==
* [[CMPXCHG8B]]
* [[Denial-of-service attack]]
* [[Pentium FDIV bug]]
* [[Meltdown (security vulnerability)]]
* [[Spectre (security vulnerability)]]

==References==
{{reflist|refs=
<ref name="Collins_1998">{{cite journal |title=The Pentium F00F Bug |url=http://www.drdobbs.com/embedded-systems/the-pentium-f00f-bug/184410555 |author-last=Collins |author-first=Robert R. |date=1998-05-01 |journal=[[Dr. Dobb's Journal]] |access-date=2015-07-27}}</ref>
<ref name="Intel_1998_Update-cmpxchg8b">{{cite book |publisher=[[Intel Corporation]] |date=1998 |chapter=81. Invalid Operand with Locked CMPXCHG8B Instruction |title=Pentium Processor Specification Update, Version-041 [Release Date January 1999] |url=http://download.intel.com/support/processors/pentium/sb/242480.pdf |url-status=dead |location=Santa Clara, California, USA |pages=51''f'' |access-date=2015-07-27 |id=Order Number 242480-041 |archive-url=https://web.archive.org/web/20160304060905/http://download.intel.com/support/processors/pentium/sb/242480.pdf |archive-date=2016-03-04 |quote=PROBLEM: The CMPXCHG8B instruction compares an 8-byte value in EDX and EAX with an 8-byte value in memory (the destination operand). The only valid destination operands for this instruction are memory operands. If the destination operand is a register, the processor should generate an invalid opcode exception, execution of the CMPXCHG8B instruction should be halted and the processor should execute the invalid opcode exception handler. This erratum occurs if the LOCK prefix is used with the CMPXCHG8B instruction with an (invalid) register destination operand. In this case, the processor may not start execution of the invalid opcode exception handler because the bus is locked. This results in a system hang. IMPLICATION: If an (invalid) register destination operand is used with the CMPXCHG8B instruction and the LOCK prefix, the system may hang. No memory data is corrupted and the user can perform a system reset to return to normal operation. Note that the specific invalid code sequence necessary for this erratum to occur is not normally generated in the course of programming nor is such a sequence known by Intel to be generated by commercially available software. This erratum only applies to Pentium processors, Pentium processors with MMX technology, Pentium OverDrive processors and Pentium OverDrive processors with MMX technology. Pentium Pro processors, Pentium II processors and i486TM and earlier processors are not affected […]}}</ref>
<ref name="Hovers_1997">{{cite newsgroup |title=Nieuwe Intel Pentium Bug |author-first1=Onno |author-last1=Hovers |display-authors=etal |date=1997-11-08 |newsgroup=nl.comp.hardware |message-id=<!--Urgently needed--> |language=nl |trans-title=New Intel… |format=newsgroup thread, 38 posts by 22 authors |url=https://groups.google.com/forum/#!msg/nl.comp.hardware/mcQfb59_1v4/1V5ohjGlio4J |access-date=2015-07-27 |quote=Als je er nog niet over gehoord hebt, er is een nieuwe Intel Pentium BUG. Daardoor is het vanuit userspace mogelijk om de Pentium helemaal te laten crashen met 1 instructie. De bug doet zich voor op de Intel Pentium en de Intel Pentium MMX. De bug doet zich niet voor op de Intel Pentium Pro, de Intel Pentium II, de chips van AMD, Cyrix e.d. Deze bug is alleen van belang voor sommige mensen die een multiuser (shell) systeem draaien op een Intel Pentium. Op zo'n systeem kan elke user het systeem crashen…}}</ref>
<ref name="Torvalds">{{Cite web |title=torvalds/linux |url=https://github.com/torvalds/linux/blob/cc0356d6a02e064387c16a83cb96fe43ef33181e/arch/x86/kernel/traps.c#L215 |url-status=live |access-date=2021-07-09 |website=GitHub |archive-url=https://web.archive.org/web/20220623154217/https://github.com/torvalds/linux/blob/cc0356d6a02e064387c16a83cb96fe43ef33181e/arch/x86/kernel/traps.c#L215 |archive-date=2022-06-23}}</ref>
}}

==Further reading==
* {{cite journal |author-last=Crothers |author-first=Brooke |title=Net reacts to "F0" Pentium bug |journal=[[CNET News]] |date=1997-11-10 |url=http://www.cnet.com/news/net-reacts-to-f0-pentium-bug/ |access-date=2015-07-27}}
* {{cite journal |title=The Pentium F00F Bug |url=http://www.drdobbs.com/embedded-systems/the-pentium-f00f-bug/184410555 |author-last=Collins |author-first=Robert R. |date=1998-05-01 |journal=[[Dr. Dobb's Journal]] |access-date=2015-07-27}}
* {{cite magazine |title=PC World |magazine=[[PC World]] |publisher=[[PC World Communications]] |volume=16 |page=55 |date=1998 |url=https://books.google.com/books?id=CEZVAAAAMAAJ |access-date=2015-07-27}}

==External links==
* [https://web.archive.org/web/20030803125206/http://support.intel.com/support/processors/pentium/ppiie/index.htm Intel Pentium erratum]
* [https://jeffpar.github.io/kbarchive/kb/163/Q163852/ Microsoft Knowledge Base article]
* [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1476 F00F] [[Common Vulnerabilities and Exposures|CVE]] bug entry

{{DEFAULTSORT:Pentium F00f Bug}}
[[Category:X86 architecture]]
[[Category:Denial-of-service attacks]]
[[Category:Hardware bugs]]
[[Category:Computer folklore]]
[[Category:1997 in computing]]