From owner-freebsd-hackers Mon Nov 17 22:54:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA26544 for hackers-outgoing; Mon, 17 Nov 1997 22:54:39 -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 WAA26532 for ; Mon, 17 Nov 1997 22:54:32 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.7/8.8.5) id BAA09940; Tue, 18 Nov 1997 01:54:30 -0500 (EST) Date: Tue, 18 Nov 1997 01:54:30 -0500 (EST) Message-Id: <199711180654.BAA09940@dyson.iquest.net> X-Newsreader: knews 0.9.8 From: root@dyson.iquest.net (John S. Dyson) Subject: Re: Better F00F workaround (well, maybe...) (fwd) To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Path: szdc!super.zippo.com!lotsanews.com!www.nntp.primenet.com!globalcenter0!news.primenet.com!nntp.primenet.com!newsxfer3.itd.umich.edu!newbabylon.rs.itd.umich.edu!joust.rs.itd.umich.edu!hasdi From: hasdi@umich.edu (Hasdi Rodzmann Hashim) Newsgroups: comp.sys.intel Subject: Re: Better F00F workaround (well, maybe...) Date: 18 Nov 1997 05:03:57 GMT Organization: University of Michigan ITD News Server Lines: 26 Message-ID: <64r7jt$lqo$1@newbabylon.rs.itd.umich.edu> References: <346F1F9B.1E53@geocities.com> NNTP-Posting-Host: joust.rs.itd.umich.edu X-Newsreader: TIN [version 1.2 PL2] Xref: szdc comp.sys.intel:72644 Mark Morgan Lloyd (mark_tbu@cix.compulink.co.uk) wrote: : > 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.) : Yeees... so what you're saying is make sure /every/ exception handler : invalidates the page containing the IDT before IRETing? I'd have thought : that would have worked except in cases where the user can install his own : x86 exception handlers (rather than Unix-style traps). You know, IA-32 supports non-cachable page. If this works, it will be easier to make the IDT entry 0..6 on a non-cachable page. Beats rewriting the exception handler. CYA. Hasdi (a happy AMD486 user) Outdated f0 bug homepage: http://www-personal.umich.edu/~hasdi/pentium_lock.htm