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 23:15:44 -0500
One last addendum, and then I'm going to bang my head against a wall or something. mycroft () MIT EDU (Charles M. Hannum) writes:
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:
Actually, that isn't quite true. RF is always set when we get the page fault. It turns out there's no way to distinguish a real trace trap from an INT 1 or ICEBP/INT01, and that full decoding of the BOUND instruction is not necessary because the saved PC points to the BOUND instruction itself. Incorporating only these two changes, the processing rules I suggested would be more correctly stated as: * If the page fault was outside the IDT, or was due to user mode access to the IDT (i.e. the U bit is set in the error code), process it as a normal page fault. * If the page fault was for vector 1, turn off the RF flag, and enter the trace trap handler. * If the page fault occured at an INT instruction: * If we're in VM86 mode, enter the protection fault handler. (This should never happen, since we should have gotten a protection fault from the hardware.) * If the page fault was for vectors 3, 4 or 5, or came from kernel space, advance the PC (always 2 bytes + prefixes) past the instruction, turn off the RF flag, and enter the handler for that exception. * If the page fault was for vectors 0, 2 or 6, and came from user space, enter the protection fault handler. * If the page fault occured at a different instruction: * If the page fault was for vectors 3 or 4, advance the PC (always 1 byte + prefixes) past the instruction, turn off the RF flag, and enter the handler for that exception. * If the page fault was for vectors 0, 2, 5 or 6, enter the handler for that exception. This leaves two semantic differences when the workaround is active, neither of which is serious: * INT 1 and ICEBP/INT01 will cause a trace fault (*not* a trace trap) rather than a protection fault. * In a SMP system, it's possible that the instruction could be modified while it's being inspected by the page fault handler. In this event, the code may do the wrong fixup, causing the wrong type of exception to be delivered. Note that the code that scans the instruction prefixes and looks for the first byte of the instruction needs to be careful to check for the end of the segment and limit how far it searches; otherwise it might be possible for another processor in a SMP system to modify the instruction sequence in such a way that the processor that took the original page fault gets stuck in a loop or runs off the end of a segment.
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)