Date: 6 Nov 1997 21:53:13 -0800
From: Tim Smith 
Newsgroups: comp.os.linux.advocacy, comp.sys.intel
Subject: Re: This code will lock up any P5 machine, even usermode Linux!  (F0 0F C7 C8)

Cool.  It also works (sic) from V86 mode, so if you want to play around, just
use DOS debug under whatever DOS emulator the OS you are using provides.
Anyone try it on a Pentium MMX?


Date: Thu, 06 Nov 1997 21:57:33 -0800
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)

        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.


Date: 7 Nov 1997 07:17:44 GMT
From: Sam Trenholme 
Newsgroups: comp.os.linux.advocacy, comp.sys.intel
Subject: F0 0F C7 C8 looks worse than FPIV

This bug looks far worse that FPIV.  Intel will probably be forced to
undergo an expensive recall, although I wonder just how Intel plans on
getting the broken Pentium on my IBM thinkpad fixed.  I like to let
co-workers access my machine when it is hooked up to the network at work,
and will have to now severely restrict any such access.

=-=

From: whiz 

>Oh dear.  This is very not good.  Without knowing machine level programing
>as well as I should, is it possible to create a patch for the, in the Linux
>kernel for example?  Will there be a significant performance hit?
>
>This code does NOT affect Cyrix 6x86 (166+ specifically, but probably all of
>them) processors.  If you run a multiuser, untrusted system, I suggest
>reserving some at your local computer supplier... unless there is an easy
>fix for this, there is going to be a run on them.
>
>I don't know if AMD's Pentium-clone chips are vulnerable.
>
>Well, it really only affects multiuser systems, where untrusted code can
>be executed.  There are so many ways to lock Windows 95 up already, one
>more cause won't make that much of a difference, and that's the vast
>majority of Pentium users.  But multiuser systems are in deep sh*t.
>
>Does anyone know if the process accounting in Linux will log the execution
>of this before it locks up the machine?  I seem to remember that it logs
>on process completion, unfortunately.
>
>And is there an NT exploit for this?

The following unpriviledged, user-mode simple C code locks up my NT 4.0
(SP3+all current hotfixes applied) workstation solid, only hard reset
helps:

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

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

       f();
}

=-=

From: Stefan Hudson 

no: Cyrix 6x86 (166+)

From: Kurt Seifried 

yes: P166
yes: P166MMX

From: George Imburgia 

Intel recently acknowledged that they enabled the ability to update
microcode on Pentium chips several years ago. That's right folks, they put
a backdoor in your hardware. The good news is, it could be used to fix
this bug, should Intel be so inclined.

AMD's microcode is updateable too. No clue about cyrix.


From: Russ 

>Tried this on several NT 4.0 (SP3) boxes here.
>
>We ran the code on a Pentium Pro and a Pentium II and all we got was an
>access violation.
>
>We ran it on a Pentium and it locked tighter than a drum.  We don't
>have a Pentium MMX to try it on, so I can't tell you that.
>

Cool.  It also works (sic) from V86 mode, so if you want to play around,
just use DOS debug under whatever DOS emulator the OS you are
using provides. Anyone try it on a Pentium MMX?