From owner-freebsd-security  Thu Nov 27 19:31:38 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id TAA15128
          for security-outgoing; Thu, 27 Nov 1997 19:31:38 -0800 (PST)
          (envelope-from owner-freebsd-security)
Received: from ren.dtir.qld.gov.au (firewall-user@ns.dtir.qld.gov.au [203.108.138.66])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA15123
          for <freebsd-security@freebsd.org>; Thu, 27 Nov 1997 19:31:34 -0800 (PST)
          (envelope-from syssgm@dtir.qld.gov.au)
Received: by ren.dtir.qld.gov.au; id NAA20211; Fri, 28 Nov 1997 13:31:42 +1000 (EST)
Received: from ogre.dtir.qld.gov.au(167.123.8.3) by ren.dtir.qld.gov.au via smap (3.2)
	id xma020188; Fri, 28 Nov 97 13:31:16 +1000
Received: from localhost.dtir.qld.gov.au (localhost.dtir.qld.gov.au [127.0.0.1])
	by ogre.dtir.qld.gov.au (8.8.7/8.8.7) with SMTP id NAA08663;
	Fri, 28 Nov 1997 13:31:19 +1000 (EST)
Message-Id: <199711280331.NAA08663@ogre.dtir.qld.gov.au>
X-Authentication-Warning: ogre.dtir.qld.gov.au: localhost.dtir.qld.gov.au [127.0.0.1] didn't use HELO protocol
To: Sean Eric Fagan <sef@kithrup.com>
cc: freebsd-security@freebsd.org, syssgm@dtir.qld.gov.au
Subject: Re: Updated f00f workaround 
References: <199711271954.LAA24160@kithrup.com>
In-Reply-To: <199711271954.LAA24160@kithrup.com>
    from Sean Eric Fagan at "Thu, 27 Nov 1997 19:54:14 +0000"
Date: Fri, 28 Nov 1997 13:31:18 +1000
From: Stephen McKay <syssgm@dtir.qld.gov.au>
Sender: owner-freebsd-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Thursday, 27th November 1997, Sean Eric Fagan wrote:

>Okay, I took Stephen McKay's suggestions to heart, and here are what I hope
>are the final diffs.  I'm currently running this kernel in multiuser mode,
>and haven't noticed any problems (yet, anyway ;)).  Overhead should be
>minimal.

The code as it stands should get people out of trouble, but I think a few
more iterations will be needed before it is acceptable to the core group
and makes it into the CVS tree.

kmem_alloc() always returns aligned memory, though in principle it could
return NULL.  So I'd change that test to 'if (tmp == NULL) panic...'

You don't need the invlpg() call because vm_map_protect() calls pmap_protect()
which calls invltlb().

I notice you make both pages read-only.  Have you tried allocating just the
one page and not making the IDT straddle a page boundary?  The workaround
info at Intel implies that would be sufficient.

The placement of your 'if (eva == ...' test implies that the page fault
will be a user mode page fault.  This looks wrong to me.  The illegal
opcode exception would be a user mode fault, but when it page faults
attempting to deliver that exception, that should be a kernel mode fault.
I would move it to after the 'if (usermode) goto nogo' test and see if
it still works.

Finally, the last bit of polish would be style related.  Having 'idt' in
the normal case and 't_idt' in the F00F bug case is not nice.  I would
have, say, 'normal_idt' and 'f00f_idt' and point 'idt' at which ever one
was being used.  Then all but a small portion of code would refer to 'idt'.
I would also be happier if "PENTIUM" appeared in the bug related naming
(it is pentium specific after all) but now we are down to minor nit picking.

Let us know how things go!

Stephen.