From owner-freebsd-security Fri Nov 14 12:41:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01983 for security-outgoing; Fri, 14 Nov 1997 12:41:39 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (qmailr@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA01969 for ; Fri, 14 Nov 1997 12:41:30 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 20229 invoked by uid 1000); 14 Nov 1997 20:40:59 -0000 Date: Fri, 14 Nov 1997 15:40:59 -0500 (EST) From: "Jay M. Richmond" To: freebsd-security@freebsd.org Subject: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 08:30:21 -0500 From: "Charles M. Hannum" To: BUGTRAQ@NETSPACE.ORG Subject: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) 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. YUCK.) 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.