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]

Message-ID: <Pine.LNX.4.64N.0709211440380.2724@blysk.ds.pg.gda.pl>
Date:	Fri, 21 Sep 2007 14:52:44 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Peter Fordham <peter.fordham@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: fpu IO port reservation (arch/i386)

Hi Peter,

> Does anybody know why we reserve this range of IO ports for 'fpu'?
> AFAIK from all the IO maps I can find on the internet for various x86
> chipsets only 0x00f0 is actaully ever used.

 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.  None of them is 
used by Linux for i486 and newer systems, which can support the FPU in its 
native configuration.

> ./arch/i386/kernel/setup.c
> 282 }, {
> 283         .name   = "fpu",
> 284         .start  = 0x00f0,
> 285         .end    = 0x00ff,
> 286         .flags  = IORESOURCE_BUSY | IORESOURCE_IO
> 287 } };

 The reason is most likely the definition of the address decoder for the 
chip-select for this range in the IBM PC -- like with all motherboard port 
I/O peripherals the smallest size of the chunk the decoder resolved to was 
16 bytes, with unused locations aliasing to defined ones.

> The reason I ask is that I've written a watchdog driver for a Nexcom
> MAX6600 server blade type device which has the watchdog control
> register at 0xF2. Currently request_region fails due to the fpu
> reservation.

 Reservations for some of the legacy ranges have been shrunk in the past; 
perhaps this one could too.  I hope you have a way to make sure not to 
interact badly with the FPU possibly being decoded there on other systems 
-- the original registers are write-only.

  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/