Date: Tue, 18 Nov 1997 01:54:30 -0500 (EST) From: root@dyson.iquest.net (John S. Dyson) To: hackers@freebsd.org Subject: Re: Better F00F workaround (well, maybe...) (fwd) Message-ID: <199711180654.BAA09940@dyson.iquest.net>
next in thread | raw e-mail | index | archive | help
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> <EJt7CM.Iyz@cix.compulink.co.uk> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711180654.BAA09940>