Date: Sun, 16 Nov 1997 12:53:21 -0500 (EST) From: root@dyson.iquest.net (John S. Dyson) To: hackers@freebsd.org Subject: Better F00F workaround (well, maybe...) (fwd) Message-ID: <199711161753.MAA23714@dyson.iquest.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711161753.MAA23714>