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 MAA01984 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 MAA01973 for ; Fri, 14 Nov 1997 12:41:30 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 20395 invoked by uid 1000); 14 Nov 1997 20:41:11 -0000 Date: Fri, 14 Nov 1997 15:41:11 -0500 (EST) From: "Jay M. Richmond" To: freebsd-security@freebsd.org Subject: Re: 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 -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzQe9IMAAAEEAKVCBVhfVHCyNOsNvCwXbamYDslPoBoUgllJxGWrjYr8+XOS mAIo6VNyR6E0Q57SICfxAlw8CfrW3jSFZxCalyAr7f4SU/ioF7qOx9AEeRePKbQD XQYT/eUirjo4h1TzQPWMrlGtnehTJfX4LKLeu8WRsMog/6LMzxBohdeuTAY9AAUR tCJKYXkgTS4gUmljaG1vbmQgPGpheXJpY2hAc3lzYy5jb20+ =PTZq -----END PGP PUBLIC KEY BLOCK----- ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 10:50:53 -0500 From: "Charles M. Hannum" To: BUGTRAQ@NETSPACE.ORG Subject: Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) > It occurs to me that there may be another way to solve this -- [...] An addendum to the previous: Not quite all entries into the page fault handler will be due to user instructions. In particular, our partially mapped IDT may cause a page fault during a normal trace trap. This should not be reexcuted; if we do so, we'll skip an instruction, which would screw the debugger. We should be able to differentiate this condition by checking for the RF flag; if it's not set, then the trap wasn't due to a particular instruction, and we should emulate it per the BSDI code. Using the RF flag, though, we could also fix the BSDI hack to not have the original caveats. If RF is set, we know that a particular instruction caused the fault, and we can always decode it to decide what to do: * If the page fault was for vectors 3-5, advance the PC past the instruction, turn off the RF flag, and enter the fault handler for the real exception. * If the page fault was for vectors 0-2 or 6, and the instruction was not INT, don't advance the PC, and enter the fault handler for the real exception. * If the page fault was for vectors 0-2 or 6, and the instruction was INT, don't advance the PC, and enter the privileged instruction handler. (Change the above rules as appropriate if you care about what happens with the undocumented INT01 instruction.) [And now I'm really going to go sleep. B-)]