Bugtraq mailing list archives
Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug:
From: mycroft () MIT EDU (Charles M. Hannum)
Date: Fri, 14 Nov 1997 10:50:53 -0500
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-)]
Current thread:
- Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: Charles M. Hannum (Nov 14)
- <Possible follow-ups>
- Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: Charles M. Hannum (Nov 14)
- Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: Charles M. Hannum (Nov 14)