Subject: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch)
From: Charles M. Hannum <>
List: current-users
Date: 11/14/1997 08:30:21
FYI, I put a patch similar in nature to the BSDI one in the NetBSD
kernel.  It seems to work, and crashme has been unable to crash my
machine so far.  However, I note three caveats to this approach:

* With this workaround, it's impossible for the kernel to distinguish
whether exceptions 0-2 and 6 occured due to an INT ${0-2,6}
instruction or due to their normal causes.  Without the workaround, an
INT ${0-2,6} instruction would normally cause a protection fault, in
turn causing the process to get a SIGBUS, because the descriptors for
these exceptions are marked as not being callable by user code.
Instead the process will get a SIGFPE, SIGTRAP, SIGBUS, or SIGILL,
depending on which of INT ${0-2,6} was executed.

* There's also no way to distinguish whether we got exceptions 3-4 due
to an INT3 or INTO instruction, or due to an INT ${3-4} instruction,
without actually inspecting the user code.  Ideally, we want to know
this so we can advance the PC the right amount; the page fault is a
restartable exception, and the saved PC points to the {INT3,INTO,INT
$N} instruction, whereas these instructions normally cause the
exception to be taken after the PC has been advanced.  Currently I
just patch the PC as if the exception always occured due to INT3 or
INTO, since no real code uses INT ${3-4}, or uses a prefix on them,
and I'd rather not slow down this path much more to check.

* The previous also applies to the exception 5 and the BOUND
instruction, which I haven't fully dealt with as of this writing.  (It
actually uses the operand size prefix, so it needs to be decoded.

Note that since VM86 mode always traps INT instructions via a GP
fault, code running in VM86 mode is unaffected by this.  In the all
too likely event that some whacked out DOS program actually uses INT
${0-6}, its behaviour inside doscmd or dosemu should not change.