linux-kernel - Re: fpu IO port reservation (arch/i386)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 21 Sep 2007 17:52:56 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	Peter Fordham <peter.fordham@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: fpu IO port reservation (arch/i386)

On Fri, 21 Sep 2007, Andi Kleen wrote:

> >  There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the 
> > coprocessor reset.  They are legacy ports resulting from the interesting 
> > way the FPU has been wired by IBM in their PC design. 
> 
> Was it really needed on 386s? I didn't think there was a IBM 386 PC.

 That comes back from the 80286-based original PC/AT and was carried over 
to the 80386 by cloners (and then the i486 and further by Intel itself, 
forced by the market).

 A way to reset the FPU was required by the 80287 part when switching back 
from the protected mode similarly to the 80286.  Like the CPU which had no 
way to clear the MSW.PE bit in software (obscure stuff of LOADALL aside; 
;-) and LMSW carried it over to the 80386 and further for compatibility), 
the FPU had no counterpart to the FSETPM instruction that was used to 
switch to the different internal address format used by the FPU in the 
protected mode (FRSTPM was only introduced to a newer 287 variation, long 
after the original PC/AT).  Note that the 80287 can be used in conjunction 
with the 80386, so some of this black magic may even apply to Linux.

 The busy latch had to be used (and cleared explicitly) because of the 
violation of the FPU exception signalling protocol as the PC/AT 
incorrectly wired the FPU error output line to IRQ 13 rather than the CPU 
error input.  This was done because IBM reused the interrupt vector range 
reserved by Intel for exception handling for hardware interrupts and (in 
this case) some of their BIOS calls.  Unfortunately, in their infinite 
wisdom, the responsible people in IBM provided no way to switch exception 
signalling in the PC/AT to the native mode (for use in the protected mode 
if nothing else).  This, too, was carried over to the 80386 and only 
sorted out by the CR0.NE bit in the i486.

 For the curious the details of all the hassle are reasonably well 
described in the Intel's AP-578 application note.

  Maciej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/