f00f-bug

From: Rick Moen (rick@hugin.imat.com)
Sender: owner-balug-talk@balug.org
To: balug-talk@balug.org (BALUG list)
Subject: Fun facts to know and tell about the F0 0F error (fwd)
Date: Mon, 10 Nov 1997 14:12:05 -0800 (PST)

Forwarded message:
From rick Mon Nov 10 14:11:51 1997
Subject: Fun facts to know and tell about the F0 0F error
To: sysadmins@hugin.imat.com
Date: Mon, 10 Nov 1997 14:11:51 -0800 (PST)
Reply-To: sysadmins@hugin.imat.com

Hey, look at what emerged last Thursday....

---<snip>---

Path: myrddin.imat.com!miwok!news.scruz.net!kithrup.com!news.Stanford.EDU!agate!howland.erols.net!cs.utexas.edu!geraldo.cc.utexas.edu!not-for-mail
From: noname@noname.com
Newsgroups: comp.os.linux.advocacy
Subject: This code will lock up any P5 machine, even usermode Linux! (F0 0F C7 C8)
Date: Thu, 06 Nov 1997 21:57:33 -0800
Organization: The University of Texas at Austin, Austin, Texas
Lines: 7
Message-ID: 3462ADCD.135B@noname.com
NNTP-Posting-Host: dial-102-5.ots.utexas.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (Win95; I)

Hi,

Check this out. If you execute F0 0F C7 C8 on a P5 it will lock the machine up. This is true for any operating system including usermode Linux. It's pretty cool. Basically, the opcodes are an invalid form of cmpxchg8b eax with a lock prefix. Has anyone seen this before? The problem doesn't show itself for the Pentium Pro or Pentium 2.

---<snip>---

Subsequent discussion on the Linux kernel mailing list, and the newsgroup:

CLAIM: AMD K5-PR133, K5 PR100, K5 PR166, K6 PR200, K6 233MMX unaffected.

CLAIM: Cyrix 166 MMX unaffected.
COUNTER: A different (but similar) assembler sequence does affect it, as shown at <http://www.heise.de/ct/art_ab97/9713030/> (in German).
COUNTER-COUNTER: Some code posted to the kernel list blocks the sequence.
COMMENT: Fixing an error in the Linux kernel's Cyrix support code renders even that fix unnecessary.

CLAIM: Cyrix 6x86L, 6x86MX, "Cyrix P166+" (whatever that is), M1P200+ unaffected.
CLAIM: However, a wide range of Cyrix chips are affected by the German variant instructions.

CLAIM: Intel P100, P120, P133, P166, P150MMX, P166MMX, P200MMX affected.
CLAIM: Intel P120, P166 unaffected. (Note contradiction.)

Season to taste, "cum granum salis".

---

In Summary: AMD K5/K6 are fine. Cyrix systems may need a (coming) kernel patch or other fix. Intel Pentium or Pentium MMX systems running Linux or NT (mainly Citrix) appear to have a problem: Any shell user can crash the machine, very easily.
---

FACT: Intel may not be able to fix, short of replacement.
FACT: There are a heck of a lot of Pentiums out there.
FACT: Intel's been trying to kill off the Pentium.
FACT: However, AMD and Cyrix make plug-compatible replacements.

FACT: Some on Usenet claim evidence that Intel knew about the bug before it surfaced on the Net. The press has been acting comatose, except CNET (Brooke Crothers, <http://www.news.com/>), which started covering the story on Friday. Then Wired News (James Glave) joined in. Now, today, Alexander Wolfe at EE Times has quoted an unnamed Intel spokesman as confirming the bug's existence (gee, thanks), and saying Intel "hopes to post information on possible workarounds within the week". (See <http://techweb.cmp.com/eet/news/97/980news/confirms.html>.)
FACT: Robert R. Collins <http://www.x86.org/> is being coy.
FACT: A. Grove's folk at <http://www.intel.com/> have zero to say.

Could get interesting.

From: Don Marti (don@pacdigital.com)
To: balug-talk@balug.org
Subject: Re: Fun facts to know and tell about the F0 0F error (fwd)
X-Mailer: Mutt 0.84
Date: Mon, 10 Nov 1997 15:13:37 -0800

On Mon, Nov 10, 1997 at 02:12:05PM -0800, Rick Moen wrote:

> Intel Pentium or Pentium MMX systems running Linux or NT
> (mainly Citrix) appear to have a problem: Any shell user
> can crash the machine, very easily.

Let's examine those innocent-looking little 32 bits more carefully, shall we?

f00fc7c8

f00: "foo" is the most recognizable traditional hacker (in the original, correct, praiseworthy sense) word; it shows up in many famous, culturally sophisticated programming contexts such as the International Obfuscated C Contest and the Jargon File. The saboteur or saboteurs are probably using a form of "foo" here to get the real hackers's attention, or to claim membership in the real hacker community.

fc: The Unabomber marked many bomb components with the initials "FC" and used this acronym in communications with the press. It is possible that the current suspect recruited Intel personnel or contractors before his arrest, or law enforcement has the wrong man, or this "FC" is the work of copycats influenced by "Industrial Civilization and its Future."

7c8: Appears to be half of a Canadian postal code; matching locations include Nepean, Ontario K2H 7C8 and Penticton, British Columbia V2A 7C8.

So, I'm sure that somebody is already rounding up the Canadian hacker Unabomber sympathizers at Intel for questioning. Any word from the rogue ActiveX control writing community?

-- 
Don Marti                   | http://goldfish.pacdigital.com/~don
Pacific Digital Interactive | A small clue and no budget will get you
don@carp.pacdigital.com     | further than a big budget and no clue.

Date: Tue, 11 Nov 1997 19:31:11 -0800
To: mhigashi@hooked.net, rick@hugin.imat.com
From: Yobie Benjamin (ybenja@ctp.com) (by way of Cassiel) Subject: Re: Pentium Bug

ar x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };

main ()
{
void (*f)() = x;

f();
}

When run in *user* mode locks up pentium processors solid. All NT, all 95 (all Intel based Linux/FreeBSD/Solarisx86) are vulnerable.

Yobie Benjamin
Chief Knowledge Officer
Cambridge Management Lab
a division of Cambridge Technology Partners, Inc.
304 Vassar Street
Cambridge, MA 02139
-or-
1300 South El Camino Real - Suite 600
San Mateo, CA 94402
ybenja@ctp.com
650/372-6204 direct
650/574-3710 main
650/533-3100 mobile
650/372-6200 fax

Date: Wed, 12 Nov 1997 09:30:58 -0800
To: Rick Moen (rick@hugin.imat.com)
From: Yobie Benjamin (ybenja@ctp.com)
Subject: Re: Pentium Bug
Cc: mhigashi@hooked.net, cassiel@dis.org, mudge@l0pht.com, weld@l0pht.com, dc-stuff@dis.org, jallison@whistle.com
In-Reply-To: 199711120814.AAA09809@hugin.imat.com

At 12:14 AM 11/12/97 -0800, Rick Moen wrote:
>[responding to a message forwarded by Solitaire, cassiel@dis.org]
>
>> Hash: SHA1
>>
>> char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>>
>> main ()
>> {
>> void (*f)() = x;
>>
>> f();
>> }
>
>Hmm. Here's my version. Slightly cleaner C code.
>
>---<snip>---
>
>char x[5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
>
>int main(void)
>{
> void (*f)(void) = (void (*)(void))x;
> f();
> /*NOTREACHED*/
> return 0;
>}
>
>---<snip>---
>
>'Course, you can also do it all in one line:
>
>long main[] = { 0xc8c70ff0 };
>
>Or, on DOS, WinDOS, NT, OS/2, or DOSEmu, you can do it without benefit
>of compiler, using (my personal favourite) just a batch file:
>
>---<snip>---
>
>set t=%TEMP%\t
>echo a > %t%
>echo dw 0ff0,c8c7 >> %t%
>echo. >> %t%
>echo g >> %t%
>debug < %t%
>
>---<snip>---

Brilliant programmatic deduction Rick!!!

>> When run in *user* mode locks up pentium processors solid.
>
>Specifically, Intel Pentium and Pentium MMX chips, but not Pentium Pro,
>Pentium II, AMD K5, or AMD K6 chips. The particular opcode cited
>does not affect any of the Cyrix chips, but a slight variant on it,
>from a German source, does affect them — except that an easy fix
>for that variant can be applied under Linux (not sure about other OSes).

Definitely not AMD & Cyrix chips but am unsure about the PP and PII.
I'll run tests tonight.

>Robert R. Collins has alleged that he's been trying to get Intel
>to acknowledge this bug for many months. They ignored the warnings
>until this week, following an anonymous post last Thursday on
>comp.os.linux.advocacy, posted from the University of Texas at Austin.

Outright bullcrap. I know the discoverer of the code.

>However, if you look on <http://www.intel.com/>, there's still no mention.
>
>Possible fixes include microcode patches, if such are possible on
>Pentiums/Pentium-MMXes, as they are with Pentium Pro/Pentium II CPUs.
>Intel is remaining mum about that question, saying only (via a brief
>mouthpiece statement quoted by CNET and EE Times) that they'd
>"attempt to have a fix by the end of this week".
>
>If that doesn't happen, then OS developers may be able to trap the
>opcode in their respective kernels — or maybe not. If not, then
>*ix sysadmins and other Pentium owners will probably buy one heck of
>a lot of Cyrix and (especially) AMD chips!
>
>> All NT, all 95....
>
>Generally, the opportunity never arises on these OSes, as they are not
>(usually) full multi-user OSes. That is, you do not generally get
>remote access to a Win32 machine's command line.

I am glad you pointed out that GENERALLY. One can package the stuff in a variety of creative ways that should not involve user knowledge or agreement.

>The obvious exception would be the (very optional) telnet daemon for NT
>distributed on MS developer CDs, the (equally optional) POSIX
>subsystem, and Citrix/NT boxes.
>
>So far, the NT/95 people have been ignoring this bug, whether out of
>characteristic catatonia or a conviction that it doesn't matter, I'm
>not sure. However, they may change their minds once the first "F0 07
>C7 C8" ActiveX controls show up. Heh, heh!

Done and already being circulated by unknown authors. M$ has announced a fix will be posted presumably to trap the bug. BUT remember this is just one bug. There may be more ;^)

>(Oops, I forgot: We're supposed to call it "Windows DNA", this week,
>rather than ActiveX.)

You're right. DNA - Devil's Notorious Architecture

>> ...(all Intel based Linux/FreeBSD/Solarisx86) are vulnerable.
>
>You forgot NeXTStep and SCO/UnixWare.

From: glen mccready (glen@qnx.com)
To: 0xdeadbeef@substance.abuse.blackdown.org
Subject: Net reacts to Pentium bug
Date: Mon, 10 Nov 1997 15:16:30 -0500

Forwarded-by: Chris Wedgwood (chris@cyphercom.com)
From: http://www.news.com/News/Item/0,4,16187,00.html

Net reacts to Pentium bug
By Brooke Crothers
November 9, 1997, 6:10 p.m. PT

update: As reaction to a new bug that crashes Intel (INTC) Pentium processors spreads across the Internet, the prevailing opinion is that the problem could be serious, though some believe that it simply points to more generic problems with computers.

The Pentium "F0" or "F00F" bug — as some are calling it — can freeze up Pentium MMX and "classic" Pentium (non-MMX) computers, machines that number in the hundreds of millions worldwide.

The bug has the potential to crash Pentium computers and could be used as a weapon for sabotage, according to Robert Collins, whose Intel Secrets Web site tracks inside information on Intel, the world's leading chipmaker.

Postings on newsgroups can differ dramatically in opinion and do not necessarily represent professional opinions. However, a consensus can indicate that a problem is potentially serious in a case such as this.

A number of postings claim that the bug is especially pernicious because it might trigger a rash of attacks on computers, based on the potential to bring down practically any computer on which people can execute programs.

But others are more reserved. "Ordinary users are not at any more risk [from the bug] than they were before of getting a program that, for instance, maliciously formats their hard drive," said John Alderson. But he adds: "Yes, this is a potentially serious problem for those who run multiuser systems that must remain reliable."

He is also skeptical of newsgroup postings because extremes are often the norm. "Many people, for whatever reason, are nothing less than blinded by their hatred for Intel. There are also those who defend Intel because they think they can do no wrong," adds Alderson.

The bug was first reported by CNET's NEWS.COM Friday afternoon. Intel is an investor in CNET: The Computer Network.

Intel says it heard about the bug for the first time Friday, but at least two people posting messages on an Intel newsgroup claim that the chipmaker knew about the bug before. Intel engineers were meeting on Friday about the bug, according to sources.

While some people posting messages believe that it is irresponsible to make the bug public because such disclosure is tantamount to disseminating diabolical data that can be used maliciously, others say it must be done.

Eventually, someone "would have found out. And then people would have wondered why PCs were going down like mad. Better to learn now than later," one posting read.

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 company's server computers, according to Collins.

From: glen mccready (glen@qnx.com)
To: 0xdeadbeef@substance.abuse.blackdown.org
Subject: Pentium Death
Date: Mon, 10 Nov 1997 15:40:13 -0500

From: Chris Wedgwood (chris@cyphercom.com)

I've seen nothing official so far, so this only comes from what I've read over the past four days days and a couple of experiments I've done. I've also not been able to test this properly as I don't have a Pentium anymore. I have, however, tested this and can confirm it doesn't affect either the PentiumPro or the PentiumII.

It has been discovered that a certain sequence of bytes when executed causes a Pentium processor (both non-MMX and MMX) to lock up. This sequence of bytes does not cause and illegal instruction exception as it does on the PentiumPro and PentiumII.

It is possible for an ordinary non-privileged user to execute these opcodes and bring a multi-user OS such as Windows NT or one of the unix flavors (even qnx!) to an abrupt halt.

This could be very serious for ISPs which give users shell accounts on such machines.

The opcode sequence is 0xf0,0x0f,0xc7,0xc8 which disassemble to (according to the gnu-binutils) "lock cmpxchg8b %eax".

It may be that the chip 'halts' internally as the temperature of a chip when halted drops and power consumption is reduced.

The AMD and Cyrix clone chips do not appear to be affected by this bug, although the same code that found these problems on the Pentium may have found similar problems on the Cyrix 6x86. (Not 100% sure here, don't have a Cyrix so didn't pay much attention).

There is some talk about this on www.x86.org. Robert Collins claims to have known about it for some months.

-Chris

P.S. If you have gcc, then try something like this:

main(){ __asm__(".byte 0xf0,0x0f,0xc7,0xc8"); }

From: glen mccready (glen@qnx.com)
To: 0xdeadbeef@substance.abuse.blackdown.org
Subject: Intel confirms Pentium flaw that could freeze PCs
Date: Tue, 11 Nov 1997 14:38:52 -0500

Forwarded-by: boerio@arocknid.com

Intel confirms Pentium flaw that could freeze PCs

By Kourosh Karimkhany

PALO ALTO, Calif., Nov 10 (Reuters) - Intel Corp. (INTC.O) said Monday it found a design flaw in its Pentium computer chip that could be exploited by malicious programmers to crash personal computers and network servers.

The flaw occurs in the Pentium and Pentium with MMX microprocessors, two of the most common chips found in personal computers worldwide, the company said.

But PC users would not encounter the flaw in everyday use. A programmer would have to intentionally issue a specific command to freeze the PC's operation.

Intel said it is moving quickly to fix the flaw because of the amount of concern it has raised during the weekend. CNET, an online technology publication, first reported the flaw Friday afternoon.

"We are doing this on an accelerated timeline," said Tom Waldrop, Intel spokesman. "It's gotten a lot of attention and it could raise a lot of concern."

On Internet newsgroups — sections on the worldwide computer network where people discuss various issues — some postings claimed that the flaw could be exploited to sabotage servers, the central computers that control the flow of information through networks.

But Waldrop said it would be unlikely to issue the illegal command through the Internet to sabotage PCs remotely.

An afflicted PC would "freeze" and not operate until it is turned off and turned back on.

Intel, based in Santa Clara, Calif., learned a painful lesson about chip flaws three years ago when some users discovered that the Pentium could not perform some math functions correctly.

Intel initially argued that the flaw was minor, but eventually had to backtrack and agree to replace the bad chips, taking a substantial hit to its earnings.

Waldrop said Intel probably will find a fix for the latest flaw within a week. The company will work with software companies and PC makers to distribute the fix.

Intel's stock fell $2.31 to $75.125 on Nasdaq.

REUTERS

From: glen mccready (glen@qnx.com)
To: 0xdeadbeef@substance.abuse.blackdown.org
Cc: bostic@bsdi.com
Subject: Re: Intel confirms Pentium flaw that could freeze PCs
Date: Tue, 11 Nov 1997 15:00:46 -0500

Forwarded-by: "Kevin D. Clark" (kclark@ctron.com)

Let me propose the following parody of the annoying Intel commercials that I see on TV occasionally:

Act I, Scene 1

There is a ticker-tape parade going on, with thousands of people present. For some odd reason, music that should never have escaped from the 70s is playing loudly over hidden speakers.

A large van, with an "Intel Inside" logo on the side, pulls up to a curb. Intel engineers, donned in annoyingly bright blue, yellow, green, pink, and red dust suits stumble out of the van, doing a dance that looks remarkably like the "funky chicken".

The van starts unfolding, allowing the onlookers to get a demo of the latest Intel(TM) technology. The engineers keep on dancing like, well, er, engineers.

Joe Random Cracker, a pimply-faced cracker-wannabe, who wouldn't know what The Right Thing was if it landed on him like a ton of bricks, is standing on the corner, watching all of this, smiling wickedly. He calls out to the Intel engineers ``Hey, look at me'', and meanwhile he starts unbuttoning his ratty flannel shirt, which reveals a tee-shirt underneath which reads:

main(){ __asm__(".byte 0xf0,0x0f,0xc7,0xc8"); }

The Intel engineers catch a glimpse of this shirt and die on the spot. All of them. The cheering stops. The ticker-tape parade is over. The terrible music stops.

THE END.

X-Digest: RISKS DIGEST 19.45
From: "Cary B. O'Brien" (cobrien@access.digex.net)
Subject: Recent Pentium opcode bug like Monoclonal Agriculture
Date: Sat, 8 Nov 1997 12:06:42 -0500 (EST)

[...] Once again I am reminded of the parallels between nearly complete market domination by a hardware or software product, and the risks of monoclonal agriculture (*).

In either case a flaw (be it a hardware error, software bug, or susceptibility to a strain of bacteria or virus) has the potential to cripple an entire industry, with serious sociological consequences. (cf., the Irish Potato Famine).

To me, at least, these parallels reinforce the importance of the government's responsibility to prevent monopolistic activity on the part of corporations. Loss of technological diversity is nearly as bad as the loss of genetic diversity (although far easier to reverse).

Cary O'Brien

(*) By this I mean when a majority of the farms grow genetically identical products.

From: glen@substance.abuse.blackdown.org
Sender: glen@shell.ncm.com
To: 0xdeadbeef@substance.abuse.blackdown.org
Subject: IE4/Pentium security - testing for both bugs
Date: Wed, 12 Nov 1997 12:24:48 -0500

Forwarded-by: Lloyd Wood (L.Wood@surrey.ac.uk)
Newsgroups: comp.sys.intel

You can now test if you're vulnerable to the more recently discovered Microsoft and Intel problems.

<URL:http://www.ee.surrey.ac.uk/Personal/L.Wood/IE4res/>

If you're running Internet Explorer 4 on a Pentium, you can easily verify for yourself that these problems exist by attempting to load this page - but do save your work first. (Internet Explorer 3 is immune.)

This page automatically exploits both the recently-discovered Pentium bug, and the recently discovered Explorer 4 res:// buffer overflow bug, via a trivial piece of autoexecuting HTML - which could easily be emailed.

Two orthogonal separate bugs combine to more than the sum of their parts; emergent behaviour due to complexity in computer systems.

From: "David L. Sifry" (david@sifry.com)
Sender: owner-balug-talk@balug.org
To: balug-talk@balug.org
Organization: Sifry Consulting
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.27 i586)
Subject: A good explanation of the Pentium F00F trap
Date: Tue, 18 Nov 1997 22:36:59 -0800

Here's a good explanation of the recent fix for the Pentuim f00f bug. It was posted to the linux-kernel list.

Dave
--
Dave Sifry http://www.sifry.com
david@sifry.com (408) 471-0667 (voice) (408) 471-0666 (fax)
The power of a concept to change people's lives for the better.

Date: Tue, 18 Nov 1997 19:48:46 -0500 (EST)
From: "Richard B. Johnson" (root@chaos.analogic.com)
Reply-To: root@chaos.analogic.com
To: Rogier Wolff (R.E.Wolff@BitWizard.nl)
cc: Linux kernel (linux-kernel@vger.rutgers.edu)
Subject: Re: F00F trap

I don't think that my scheme would allow that. Remember that the idea is to NOT lock on the illegal instruction that contains the lock-prefix. The CPU sees the illegal instruction, it would normally lock, but can't because the IDT to handle the illegal instruction trap is not in memory. It therefore executes a page-fault (which is just another kind of trap). What we did was just prevent the lock-prefix from doing anything. So far, so good.

Note that we did not fault on the user's code. If there wasn't the lock-prefix, the user's code would have caused an illegal instruction trap. All we did, so far, is arrange a way of getting the CPU to ignore the lock-prefix.

Control will return to the instruction that caused the page-fault which is not the lock-prefix.

You can easily check this on the present kernel by modifying the F00F trap to just load the good IDT and then goto the "out:" label in fault.c. The first occurance of the F00F instruction properly causes a user-mode illegal instruction trap. The problem is that a "good" IDT is now present <forever> and the second time you try to crash the system, you will. So the idea is to have the kernel get control to restore the "bad" IDT.

Now, after considerable thought, and the reason why I am c.c.ing this to linux-kernel, the IDT really doesn't have to be reloaded either. The bottom part can really exist in memory, but its page can be marked as "not present". There is a bit for this in the page-table. It is possible to perform the same function without reloading anything. I think that the handlers for the first 6 traps can mark the page as not present after they execute and the kernel starts with that page marked not present.

Then the code-flow is:

(1) User executes bad instruction
(2) CPU page-faults because IDT lower page is not present.
(3) Kernel PF routine marks lower IDT page present.
(4) Control returns to user (it's restartable).
(5) User code traps to proper kernel handler.
(6) Kernel handler marks IDT lower page not present.

Everybody lives happily thereafter.

Even CPUs that are not faulty could do this. Marking a page present or not present does not use many CPU cycles. It's a normal virtual memory thing.

Cheers,
Dick Johnson

Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.1.63 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

X-Digest: RISKS DIGEST 19.47
From: shadow@krypton.rain.com (Leonard Erickson)
Subject: Re: New Pentium flaw (someguy, RISKS-19.46)
Date: Mon, 17 Nov 1997 22:50:30 PST

someguy@somethingorother.com writes:

> Here is how to use DEBUG to create a DOS executable that exercises the new
> flaw. DEBUG is available on DOS, Windows 3.x/95/NT and OS/2, and maybe
> others.

No need to use DEBUG. Every single one of the 4 bytes required can be entered directly from the keyboard!

Get to a DOS prompt and type this:
copy con kill.com
And then hit return.
Hold down the alt key and type 240 using the numeric pad.
Release the alt key.
Hold down the alt key and type 15 using the numeric pad.
Release the alt key.
Hold down the alt key and type 199 using the numeric pad.
Release the alt key.
Hold down the alt key and type 200 using the numeric pad.
Release the alt key.
Press the F6 key.
Press enter.

You now have the KILL.COM file... Run at your own risk.

As an old sig file says: Real programmers use COPY CON FILE.EXE

Leonard Erickson (aka Shadow) shadow@krypton.rain.com

X-Digest: RISKS DIGEST 19.47
From: Stanley@@nr1.ottawa.istar.net (Robert Stanley)
Subject: Re: New Pentium flaw (someguy, RISKS-19.46)
Date: 18 Nov 1997 14:47:39 GMT

I was amused, and pleased, to note that running this in the DOS box of an OS/2 Warp system resulted in an OS/2 exception, which is a recoverable situation, and not a halt-and-catch-fire of the Pentium.

Robert Stanley -- Stanley@Simware.COM

X-Digest: RISKS DIGEST 19.47
From: "Pekka Pietik{inen" (pp@netppl.fi)
Subject: Re: Pentium Fix?
Date: Tue, 18 Nov 1997 09:49:00 +0200

Actually the fix is far more clever than checking the memory for that instruction sequence, and works perfectly.

connecting (ROOT):~ >./crash
<c2800fc8/c2800ff8>
<handler c01094b8... ... done>
zsh: illegal hardware instruction ./crash

model : Pentium 75+
vendor_id : GenuineIntel
stepping : 5
f00f_bug : yes

The fix (described in www.intel.com) basically puts the IDT (a list of addresses the processor jumps to when various software interrupts like illegal instructions or page faults happen) on a page boundary so that the first thing on the next page is 0xe (page fault), and instruction fault is on the first page.

The first page is left unmapped. When someone runs the f00f code (or any invalid instruction) the processor naturally tries handles the invalid instruction. Before the fix the processor would have died while handling it, but since it can't jump to the handler because it can't find the address to jump to, it gets a page fault. This page fault puts the processor into a sane state, and now some code in the page fault handler can check what really happened and handle the situation properly.

The fact that this fix works is only caused by the fact that the instruction fault (and nothing performance-critical) happens to be before the page fault in the IDT. If it hadn't been, Intel would be in some trouble. There is a small performance loss, but it's unnoticeable.

Pekka Pietikäinen, Net People Ltd., Oulu, Finland

[The above messages relating to the new Pentium flaw
are just a sampling of those received. PGN]

From: Rick Moen (rick@hugin.imat.com)
Sender: owner-svlug@svlug.org
To: svlug@svlug.org (SVLUG list)
Subject: [svlug] F00F Bug follow-up
Date: Sun, 1 Mar 1998 18:43:35 -0800 (PST)

It's been amusing to watch the spin-control efforts on the Pentium "F00F" or Halt-and-Catch Fire bug, discovered last year. That bug allows any Intel Pentium/Pentium MMX to be remotely and anonymously caused to hang, merely by sending it byte sequence "F0 0F C7 C8".

Robert Collins notified Intel of the bug, twice, months before the controversy broke on Usenet, but Intel did nothing until an anonymous post from U. of Texas appeared on comp.os.linux.advocacy. (News reports incorrectly claimed that the story broke on comp.sys.intel, and CNET rather pathetically credited itself.)

Eventually, Intel opened a P.R. Web page, at http://support.intel.com/support/processors/pentium/ppiie/index.htm, rather soothingly dubbing the bug the "Pentium Processor Invalid Instruction Erratum". (Never say "bug", and certainly never "the Pentium bug".) Intel released technical information only under non-disclosure, which helped BSDI release a binary-patch fix, which the Linux kernel team then reverse-engineered and implemented in improved form.

And that was the end of the story, it seemed. For many months, the motley collection of "Vendor Statements" at http://support.intel.com/support/processors/pentium/ppiie/software.htm quoted BSDI and Linus saying "We fixed it" and everyone else saying "We're working closely with Intel...." (Meaning, "We're caught with no remedy and no plan to acquire one" — except Novell, which clarified that NetWare is unaffected.)

For many months, Microsoft's vendor statement said essentially "We're working closely with Intel [blah, blah], but it really doesn't matter, because only malicious code could trigger the bug." (Well, yes, only "malicious code" can trigger it, but the huge number of ways a machine can be made to run code, especially with brain-damaged, insecure software, means it does matter. For example, ActiveX.)

However, recently, Microsoft has quietly appended to its vendor statement a reference to a "more information" page, at http://premium.microsoft.com/support/kb/articles/q163/8/52.asp [1], "Invalid Operand with Locked CMPXCHG8B Instruction". (Gee, nobody wants to say "Pentium bug", huh?) That page reveals that Microsoft has finally snuck out "hotfixes" for NT 3.51 and 4.0 — but not for any revision of Win95. (Hotfixes are patches not yet included in any service pack, that come with no guarantees and have not undergone regression testing.)

One interesting aspect of all this is how well both Intel and Microsoft have mastered the art of damage control via management of on-line bug information. This is really a much more serious bug than the infamous Pentium math bug, but never quite crossed over from geekdom into the public consciousness.

Both companies waited until their more clueful customers' complaints reached an adequate volume, and then put up Web pages with mind-numbingly bureaucratic descriptions, that were as difficult to come across by accident as possible. This minimally placated the technical community, while avoiding alarming corporate executives, or even making them aware of the problem. With luck, the few who do stumble over the page will not recognise the problem or its severity, from the provided description.

This approach has been applied in other areas, too: When Microsoft produced hotfixes that kinda-sorta addressed some (possibly not all) variants of the Ping of Death attack, the patch is classified as "icmp-fix" and the symptom described as "A Stop 0x0000000A occurs in Tcpip.sys when receiving Out of Band (OOB) data."

Doesn't sound much like "An anonymous stranger crashes your system by sending it Ping of Death packets from somewhere halfway around the world", does it?

As codebases (such as NT 5 beta) keep going up into additional millions of lines of code, and corporate purchasers become increasingly clueless and susceptible to manipulation, I figure we can expect bug information from vendors to become ever more opaque and hidden. You will have to go through many layers of Web pages with mandatory questionnaires, to get to any kind of technical information, and then will only see what you can find in the vendor's indexes. To use those indexes half-way effectively, you'll have to learn the vendors' soothing nicknames du jour for any bugs you're interested in. (Er, I meant "issues" or "errata". Sometimes "problems". But never "bugs".)

You will find less and less useful bug information by delving through ftp sites: The vendors are tending not to see your serendipitous discoveries as being to their advantage. They prefer to keep a sharp eye on what you find and are interested in, accumulate mandatory survey information on you so they can spam your USPS and e-mailboxes, and present the appropriate spin on whatever knowledge they're obliged to give you.

Welcome to 1998. We're from the Marketing department. We're here to help you.

-- 
Virtual Regards,
Rick Moen
Sysimperator, dominus regis deusque machinarum.
rick@linuxmafia.com

RM adds, in 2005-09: The Microsoft article on that subject is long-gone, but there's a replacement page here: http://support.microsoft.com/kb/163852/EN-US/ They never did get around to fixing Windows 95, and never did a fix as part of a regression-tested service pack for NT 3.5x, only for NT 4.0.

From: rob walker (rob@svlug.org)
Sender: owner-svlug@svlug.org
To: svlug@svlug.org
Subject: [svlug] fwd: Intel F00F Bug follow-up
Date: Tue, 3 Mar 1998 00:33:23 -0800

This is a twice-forwarded note. I forwarded it from the bounce box to the svlug.org list.

Mitch explains where it came from prior to that.

From: mfw@datamain.com
Date: Mon, 2 Mar 1998 13:18:16 -0800
Disposition-Notification-To: mfw@datamain.com
Errors-To: mfw@datamain.com
Reply-To: mfw@datamain.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailer: Mitch's Much Modified Mail Mangling Mechanism (0.0.3 beta-3 2/4/98)
To: svlug@svlug.org
Subject: fwd: Intel F00F Bug follow-up

I have recently had some communication with Joe Buck — keeper of the g++ FAQ, awesome chip design software dude, and generally cool person. Joe is time-compressed and does not subscribe to SVLUG. Joe's home page is http://www.synopsys.com/pubs/research/people/jbuck.html. Anyway, here is Joe Buck's response to Chris's rant.

> One interesting aspect of all this is how well both Intel and Microsoft
> have mastered the art of damage control via management of on-line bug
> information. This is really a much more serious bug than the infamous
> Pentium math bug, but never quite crossed over from geekdom into the
> public consciousness.

Sorry, that's just wrong. With the division bug, there was no software fix that didn't reduce the performance of the processor. With the F00F bug, there is a relatively straightforward fix (the one in Linux) that doesn't impact performance. Given this fix, I don't feel that I must have a new CPU in my Pentium box at home. With the FDIV bug, I would have insisted on a fix.

Now, before the fix existed, it was a more severe bug. But with exponentially increasing processor complexity, we're just going to have to get used to this: processors are going to have bugs. If there is an OS workaround that avoids performance penalties, and these workarounds are made available without NDAs, then this is acceptable. As software folks, we can hardly beat up the hardware folks when our stuff is so much buggier than theirs.

The answer to Intel and Microsoft's PR attempts is to keep them honest.

From: Rick Moen (rick@hugin.imat.com)
To: rob@svlug.org
Cc: svlug@svlug.org
Subject: Re: [svlug] fwd: Intel F00F Bug follow-up
Date: Tue, 3 Mar 1998 02:58:49 -0800 (PST)

Joe Buck, generally cool person, wrote (somewhere off-list):

>> One interesting aspect of all this is how well both Intel and Microsoft
>> have mastered the art of damage control via management of on-line bug
>> information. This is really a much more serious bug than the infamous
>> Pentium math bug, but never quite crossed over from geekdom into the
>> public consciousness.
>
> Sorry, that's just wrong.

Really, now? Let's see:

> With the division bug, there was no software fix that didn't reduce the
> performance of the processor. With the F00F bug, there is a relatively
> straightforward fix (the one in Linux) that doesn't impact performance.
> Given this fix, I don't feel that I must have a new CPU in my Pentium
> box at home. With the FDIV bug, I would have insisted on a fix.
>
> Now, before the fix existed, it was a more severe bug.

Obviously, *I meant* before the fix existed. Sheesh, cool person. (Generally.)

One might add, further, that for most people the fix does not yet exist. The public are completely unaware of how much at risk their machines are. The point of my post was to examine how and why that state of affairs came about.

> The answer to Intel and Microsoft's PR attempts is to keep them honest.

Well, I never could have figured that one out!

-- 
Cheers,                                 For good netiquette,
Rick Moen                         be wise and choose a four-line
rick@linuxmafia.com                    .sig (haiku is good).
(and my name isn't "Chris", either)

It's the target that supposed to go "F00F", not the processor. — Mike Andrews, on Pentiums in missiles, in alt.sysadmin.recovery