That's the problem -- it isn't a "bug", just an exploitable
instruction set that Cyrix, AMD, et al have been faithfully copying.
For that matter, the 486 instruction set is a subset of the
Pentium instruction set. Does this affect the 486/386 etc..?
Short summary. The illegal instruction F0 0F C7 C8 locks up the
Pentium, only reset or NMI allows the cpu to continue (this is a lock
cmpxchg8 instruction with a reg as destination; in this case AX, but all
other regs work, too; I'm not really sure if NMI cleans it up). It
doesn't halt AMDs, Cyrixes, PPros and PII, nor does it halt any Intel CPU
before Pentium; it's supposed to produce an illegal instruction trap.
It does not halt the pentium, if the offending instruction is the
destination of a mispredicted branch, or if the illegal instruction IDT is
in the L1 cache.
Affected: Multiuser systems facing "wannabe" hackers; all Pentium and
Pentium MMX processors are affected.
Workaround: none, if disabling the L1 cache and loading the illegal
instruction IDT with TR4/TR5 isn't an option for you (massive performance
hit). A boardlevel workaround seems to be possible (LOCK hold for more
than a few microseconds -> raise NMI).
History: Is known to Intel for at least some months (the maintainer of the
Intel secret page found this bug, reported it, and did not publish it).
They did not fix it (thus even the most recent Pentia are affected).
Reproduce:
Unix:
% cat >pentbug.c
unsigned main = 0xC8C70FF0;
^D
% cc pentbug.c -o pentbug
% ./pentbug
(thanks to bernd paysan)
vijay
can this 'discussion' please be moved to ms-dos-weenies or something?
randy
But what about people using pentiums in unix-based gateways that run BGP?
And don't tell me they should be shot either.
Leo Seto
Lawrence Berkeley National Laboratory
Voice: (510) 486-5835
Pager: (888) 474-0137
E-Mail: lseto@mhgc.lbl.gov
But what about people using pentiums in unix-based gateways that run BGP?
gated does not have that illegal instruction sequence in it. compilers
don't generate it. httpd does not have the sequence.
maybe BBS operators will be interested as they have users on their machines.
but i am sure there are mailing lists for BBS operators.
randy
[ On Wed, November 12, 1997 at 10:15 (PST), Randy Bush wrote: ]
Subject: Re: Potentially dangerous Pentium bug disc
gated does not have that illegal instruction sequence in it. compilers
don't generate it. httpd does not have the sequence.
No, httpd certianly should not contain the illegal instruction within
itself, but being the complex critter it is it we find that it commonly
executes other programs on behalf of the remote user. You might want to
peek at: CERT Advisory CA-97.25 - CGI_metachar.
There's no clear exploit implied that involves the CPU hang bug (unlike
the corresponding browser bug that's already been discussed), but it
clearly identifies some very real risks that could lead to such exploits.
gated does not have that illegal instruction sequence in it. compilers
don't generate it. httpd does not have the sequence.
Even on closed systems, the exposed daemons (sendmail/smap, httpd,
gated, inetd) can not be safely said to not have buffer overflow
holes, as new ones are found periodically. What this means is that
anyone can overflow a buffer into stack space and pop code in in
place of a return.... whereas the threat profile this used to present
was that someone could go through all sorts of gyrations, upload a
tiny exploit to hack root, etc., the threat profile it now presents is
quite a bit more serious -- they now have the functional equivalent of
a user-mode "halt" instruction. While you used to be fairly safe if
you ran smap (for instance; i don't know of any specific holes in
smap) in a chrooted jail, now that defense doesn't stop some punk from
kicking your butt offline.
While I'd rather see this thread continued in more appropriate fora, I
observe that Intel hardware has found its way into my infrastructure
(and I'd suspect the infrastructure of even some large ISPs) because
its excellent price-performance figures allow us to swallow our pride
(and distaste at certain aspects of the architecture) and deploy them
in a production environment. Because of the potential operational
impact of this misfeature, I must concede that nanog is not a wholly
inappropriate forum for this discussion and I must politely disagree
with my esteemed colleague from Washington State. 
---Rob
and there are serious problems with overheating disk drives. considering
the general drivel here, that discussion will fit right in. hell, infant
teething problems probably affect many of us and cause typing mistakes the
next day (why did someone at uunet type test forwarding basic). if we put
the teethers directly on the list, the content might improve!
randy
Right on cue. I _told_ someone you'd be first.
You may not run any networking gear that uses Pentium CPUs, but there
are _many_ who do. The message was posted to NODlist as well, anyone
who's afraid of pissing Randy off, take it there.
Cheers,
-- jra
Grow up, Randy.
Cheers,
-- jra
Hello Randy, You seem to be part of the problem ... JimL
> can this 'discussion' please be moved to ms-dos-weenies or something?
Right on cue. I _told_ someone you'd be first.
You may not run any networking gear that uses Pentium CPUs, but there
are _many_ who do. The message was posted to NODlist as well, anyone
who's afraid of pissing Randy off, take it there.
not to get to off topic and such.. but it feels slightly approriate
to say that linux 2.1.63 already has a bug fix for the pent F0 0F bug..
got this from a friend who's running a 2.1.x kernel..
checking for F00F bug ...<6>
Intel Pentium/[MMX] F0 0F bug detected - turning on
workaround.
moving IDT ... ... done
[root@dilithium /]# ./pentium_lockup
Illegal instruction (core dumped)
apparently it traps the op codes before they go on to the cpu..
.---------------------------------------------------------
Aaron Beck, Internetworking Engineer. E: aaronb@mpl.net
Meridian Partners Limited. We Simply Do More. http://www.mpl.net
`------------------------------------------------------------------