Date: Thu, 13 Nov 1997 12:30:43 -0800 (PST) From: Sean Eric Fagan <sef@kithrup.com> To: hackers@freebsd.org Message-ID: <199711132030.MAA16638@kithrup.com> In-Reply-To: <Pine.BSF.3.96.971113130811.6998B-100000.kithrup.freebsd.hackers@phoenix.its.rpi.edu> References: <Pine.BSF.3.96.971113111843.26396A-100000@spiv.fnal.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
>I would be interested in seeing the alledged Linux 'fix'. But not interested enough to read the other messages in the thread, or do a simple scan of comp.os.linux.announce to see if it cropped up there? (Which it did, in fact, yesterday.) I grabbed the patch, and looked at what it did. It's fairly straightforward -- it takes the interrupt descriptor table (IDT), and moves it into a new location, starting at 7 entries below the page boundary. That is (bah, where's Terry's line-art drawing program when you need it?): idt entry 0 idt entry 1 idt entry 2 idt entry 3 idt entry 4 idt entry 5 idt entry 6 <-- just before end of 4096-byte page idt entry 7 <-- at begining of 4096-byte boundary idt entry 8 ... It sets the IDT register to point to 'idt entry 0' (using the "lidt" instruction; we have a function in locore.s that does that). Then, it removes the mapping for that page -- it leaves the mapping for the one containing 'idt entry 7', though. (This is important, because the page fault entry needs to be mapped, for somewhat obvious reasons ;).) Those vectors are for: divide, debug, nmi, breakpoint, overflow, bounds check, illegal instruction, and then device not available is in the page that stays mapped. The illegal instruction is the important one -- that is the one that will cause a page fault when lock cmpxchg8b %eax is executed, if the page is unmapped. (If it is mapped, of course, then the processor locks up if it is a Pentium.) Then, in the kernel's page fault handler, it examines the address that caused the fault (register %rc2); if the address was in the range of the unmapped IDT entries, the handler then dispatches the correct function; otherwise, it continues as normal. The BSDi fix appears to do the same thing, although I think they may have done it slightly wrong. Also, I've seen one report from someone that a 75MHz Pentium still hangs, under Linux with the patch. I haven't seen any confirmations for that, though. The performance impact of this, under linux at least, is minimal -- of the unmapped vectors, only overflow and bounds check are likely to be used by a real program in a time-critical way; page faults will take a slight hit -- three comparisons, two loads, an add, and a couple of branches as part of the if statement. I have been trying to get this working in FreeBSD since last night; right now, I'm not sure why what is happening is happening. But I'm giving up -- I've had it "explained" to me by Jordan that even if I got it working, it would not be considered, because this is simply not anything that anyone needs to worry about. (Even though I do know someone whose machine has been crashed four times since Friday by this. But since he's running SCOnix instead of FreeBSd, he doesn't count -- never mind the fact that, even if he were running FreeBSD, he'd be affected.) So all you people who are worried -- either switch to a different processor (the Cyrix chips should do fine, as should the IDT WinCPU or whatever they call it), or switch to Linux or an SCO OS. Or wait until Intel deigns to say what the official workaround is, and then wait however long it takes David Greenman to come up with an implementation that he thinks is aesthetically pleasing to him. (I am desperately hoping that he already has an implmentation, but just isn't releasing it, so that any delay after Intel decides that we're all worthy can be minimized. But if he has, he hasn't told anyone -- probably a smart thing, since he'd be flooded with requests, probably.) (And, yes, I find Jordan's attitude that nobody should care, since there are other things that can be done to destroy a system, offensive. Just as offensive as Intel's official suggestion that you can always reboot your system.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711132030.MAA16638>