From owner-freebsd-current Wed Nov 12 18:10:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA03182 for current-outgoing; Wed, 12 Nov 1997 18:10:40 -0800 (PST) (envelope-from owner-freebsd-current) Received: from zippy.dyn.ml.org (spain-39.ppp.hooked.net [206.169.228.39]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA03176 for ; Wed, 12 Nov 1997 18:10:32 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.8.7/8.8.7) with ESMTP id SAA01476 for ; Wed, 12 Nov 1997 18:11:16 -0800 (PST) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs X-Received: from mail.hooked.net (localhost [127.0.0.1]) by zippy.dyn.ml.org (8.8.7/8.8.7) with ESMTP id QAA00975 for ; Wed, 12 Nov 1997 16:25:05 -0800 (PST) X-Received: from mail.hooked.net by zippy.dyn.ml.org (fetchmail-4.3.0 IMAP run by garbanzo) for (single-drop); Wed Nov 12 16:25:06 1997 X-Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by mom.hooked.net (8.8.5/8.8.5) with ESMTP id PAA28841; Wed, 12 Nov 1997 15:54:41 -0800 (PST) X-Received: from unknown@netspace.org (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <70663-14100>; Wed, 12 Nov 1997 18:37:37 -0500 X-Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 5593970 for BUGTRAQ@NETSPACE.ORG; Wed, 12 Nov 1997 18:34:59 -0500 X-Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id SAA05390 for ; Wed, 12 Nov 1997 18:34:15 -0500 X-Received: from unknown@netspace.org (port 12859 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <70609-14103>; Wed, 12 Nov 1997 18:34:13 -0500 Approved-By: aleph1@UNDERGROUND.ORG X-Received: from snowcrash.cymru.net (snowcrash.cymru.net [163.164.160.3]) by netspace.org (8.8.7/8.8.2) with ESMTP id RAA29536 for ; Wed, 12 Nov 1997 17:33:36 -0500 X-Received: from lightning.swansea.linux.org.uk (the-great-packet-bucket-in-the-sky [163.164.160.21] (may be forged)) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id WAA23901; Wed, 12 Nov 1997 22:33:31 GMT X-Received: by lightning.swansea.linux.org.uk (Smail3.1.29.1 #2) id m0xVlPK-0005FuC; Wed, 12 Nov 97 22:37 GMT Content-Type: text Message-ID: Date: Wed, 12 Nov 1997 22:37:10 +0000 Reply-To: Alan Cox From: Alan Cox Subject: Re: mode of the i586 F0 bug X-To: vax@LINKDEAD.PARANOIA.COM To: BUGTRAQ@NETSPACE.ORG In-Reply-To: <199711122119.PAA17138@linkdead.paranoia.com> from "VaX#n8" at Nov 12, 97 03:19:34 pm ReSent-Date: Wed, 12 Nov 1997 18:11:14 -0800 (PST) ReSent-From: Alex ReSent-To: current ReSent-Message-ID: Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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 ..