Linux has patched the Pentium bug already. The patch involves handling
some low traps in the page fault handler, which is pretty ugly. Alan
Cox has verified that this is also what is happening on a patched BSDi
box.

For more details browse around
http://linuxwww.db.erau.edu/mail_archives/linux-kernel/Nov_97/thread.html#start

Also: BSDI has already withdrawn the patch, which bodes ill.

------- Start of forwarded message -------
From: rcollins@slip.net (Robert Collins)
Newsgroups: comp.sys.intel,comp.os.linux.advocacy
Subject: Re: Intel Pentium Bug: BSDI Releases a patch!
Date: 12 Nov 1997 11:54:06 -0800
Organization: Intel Secrets Web Site:  http://www.x86.org
Message-ID: <64d1gu$77s@slip.net>
References: <64bitf$8cf@sifon.cc.mcgill.ca> <34696B0D.DAD2415C@home.com>
Reply-To: rcollins@x86.org

In article <34696B0D.DAD2415C@home.com>, S.D.G. <seth@home.com> wrote:
>Hey Now,
>
>  Hmm... I would hypothesize that this fix does not simply disable the
>L1 cache; Since it adds 4k to kernel memory, perhaps it is a
>modification of the executable loader?  Someone should test the
>performance of the system before and after the path is installed...

Nope, I doubt it.  4 KB is exactly the size of a page in page mode.
I've got a hunch that they've mapped IDT vectors 0-6 in a not present
page.  Instead of getting an invalid opcode exception, a page fault
will occur instead.  The page fault handler would then determine if
the cause was this bogus opcode.

If this is how it's done, it a horrible kludgey fix.  I would not find
this type of fix acceptible under any circumstances (even if it works).

The Linux group just released their own patch for this bug (in kernel
2.1.63) and is available at http://www.kernel.org.  The method described
above, is essentially the method that Linux uses.  This would explain
a lot about the BSDI fix.

(Stepping out on a big assumption here, below...)
The #PF handler gets a bit more complex.  Now, the CR2 address points to
the faulting exception handler (if #UD or lower).  Oh great, that's just
great.  So it's not a difficult fix, but it's not an acceptible work
around, either.  The added complexity is not a acceptible under any
circumstances.  NMIs don't take NMIs; #DEs don't take #DEs.  That's not
an acceptible workaround, even if user software can't tell the difference.

Now, let's talk about keeping this information under NDA.  Some things
never change with these guy's.

-- 
"Intel Secrets -- What Intel doesn't want you to know"(  )     Robert Collins
HomePage:  http://www.x86.org               Anonymous FTP:  ftp://ftp.x86.org
-----------------------------------------------------------------------------
Robert Collins              mailto:rcollins@x86.org              408.832.6270
------- End of forwarded message -------