From owner-freebsd-hackers  Sun Nov 16 09:53:30 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA02800
          for hackers-outgoing; Sun, 16 Nov 1997 09:53:30 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA02789
          for <hackers@freebsd.org>; Sun, 16 Nov 1997 09:53:24 -0800 (PST)
          (envelope-from toor@dyson.iquest.net)
Received: (from root@localhost)
	by dyson.iquest.net (8.8.7/8.8.5) id MAA23714;
	Sun, 16 Nov 1997 12:53:21 -0500 (EST)
Date: Sun, 16 Nov 1997 12:53:21 -0500 (EST)
Message-Id: <199711161753.MAA23714@dyson.iquest.net>
Mime-Version: 1.0
X-Newsreader: knews 0.9.8
From: root@dyson.iquest.net (John S. Dyson)
Subject: Better F00F workaround (well, maybe...) (fwd)
To: hackers@freebsd.org
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Is this a good idea?

Path: szdc!super.zippo.com!lotsanews.com!news-feed.inet.tele.dk!bofh.vszbr.cz!news.maxwell.syr.edu!news-was.dfn.de!news-kar1.dfn.de!news-fra1.dfn.de!news-ber1.dfn.de!zrz.TU-Berlin.DE!news.tu-chemnitz.de!not-for-mail
From: Michael Tippach <wuschel@geocities.com>
Newsgroups: comp.sys.intel
Subject: Better F00F workaround (well, maybe...)
Date: Sun, 16 Nov 1997 17:30:19 +0100
Organization: University of Technology Chemnitz, FRG
Lines: 26
Message-ID: <346F1F9B.1E53@geocities.com>
NNTP-Posting-Host: tiwu.csn.tu-chemnitz.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01 (WinNT; I)
Xref: 	szdc comp.sys.intel:72500

Hi all!

Anyone else willing to confirm that (at least with paging enabled) the #UD
WILL be triggered if (and _only_ if) the idt lookup causes a TLB miss?

Seems to be the sole condition for making "it" happen or not.

Consructing a simple system where the handlers for exceptions 0..6
(alignment as in the Intel workaround) just do an invlpg [first_idt_page]
enabled me to reliably trap any mutation of the f00fc7c8 (There are
more than 8 possible mutations BTW since you can add prefixes in addition
to the LOCK without changing anything to the matter.)

The OS still would have to make sure the invlpg is done after _any_
access to the page in question, which shouldn't be too hard either.

Just in case I'm right, wouldn't this provide a better workaround compared
with the page fault mess in Intel's fix description?


Best regards
Michael Tippach