From owner-freebsd-hackers Wed Nov 12 19:34:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08623 for hackers-outgoing; Wed, 12 Nov 1997 19:34:44 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08574 for ; Wed, 12 Nov 1997 19:34:39 -0800 (PST) (envelope-from max@iclub.nsu.ru) Received: from localhost (max@localhost) by iclub.nsu.ru (8.8.7/8.8.5) with SMTP id JAA22641 for ; Thu, 13 Nov 1997 09:35:11 +0600 (NS) Date: Thu, 13 Nov 1997 09:35:11 +0600 (NS) From: Max Khon To: freebsd-hackers@freebsd.org Subject: BSDI F0 bug workaround implementation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, there! ---------- Forwarded message ---------- Date: Wed, 12 Nov 1997 22:37:10 +0000 From: Alan Cox To: BUGTRAQ@NETSPACE.ORG Subject: Re: mode of the i586 F0 bug > manufacturer that the Intel hardware designers forgot to unlock the > bus before trying to load the descriptor for the appropriate > exception handler, which would explain why locking it into the > L1 cache helps. I suppose the hardware does unlock it before actually It would also explain how the real fix works. If you take a BSDI box after the patch and before the patch and compare the MMU tables via /dev/mem etc you'll find there are a pair of funny pages where the interrupt descriptor table has moved. Odder still the low part of it doesnt have a pte. What it seems is done is to put the low descriptors into an invalid page and take a page fault when it tries to handle the fault from the lock cmpxchg8. The linux code is based on this observation and does this trick. The page fault handler then checks the fault and sees a kernel mode fault on the descriptor block[1] and works out what the real fault was. It then calls the relevant kernel function instead of doing normal page fault processing. We could probably just remap the page then but its faster to call the functions by hand than map and remap the page (causing tlb flushes). Hopefully that info and the 2.1.63 linux patch is enough to get the fix into other free OS's too. And if anyone can find a way to break the linux 2.1.63 fix we'd all love to know. Hopefully a complete official intel workaround will appear shortly and we can switch to that. Alan [1] This is important - or we might take a fault for a user process at the same address by chance and do a trap instead ..