linux-kernel - Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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:	Tue, 01 Jan 2008 13:44:19 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Rene Herman <rene.herman@...access.nl>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David P. Reed" <dpreed@...d.com>,
	Rene Herman <rene.herman@...il.com>,
	Ingo Molnar <mingo@...e.hu>, Paul Rolland <rol@...917.net>,
	Pavel Machek <pavel@....cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	rol@...be.net
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

Rene Herman wrote:
> On 01-01-08 22:15, H. Peter Anvin wrote:
> 
>> I have mentioned this before... I think writing zero to port 0xf0 
>> would be an acceptable pause interface (to the extent where we need an 
>> I/O port) except on 386 with 387 present; on those systems we can fall 
>> back to 0x80.
> 
> PII 400 / Intel 440 BX (PIIX4):
> 
> rene@...p:~/port80$ su -c ./portime
> out 0x80: 544 cycles
> in  0x80: 254 cycles
> in  0x61: 254 cycles
> out 0xf0: 544 cycles
> 
> The Intel PIIX/PIIX3 datasheet specifically mentions that both reads and 
> writes at 0xf0 "flow through to the ISA bus".
> 
> However, more complete, it says:
> 
> "Writing to this register causes the PIIX/PIIX3 to assert IGNNE#. The 
> PIIX/PIIX3 also negates IRQ13 (internal to the PIIX). Note that IGNNE# 
> is not asserted unless FERR# is active. Reads/writes flow through to the 
> ISA bus".
> 
> We don't want the side-effects, do we?
> 

Yes, we do.  It's exactly this side effect which makes this safer than 
either 0x80 or 0xED -- it's a port that *guaranteed* can't be reclaimed 
for other purposes without breaking MS-DOS compatibility.

It's specifically a side effect *we don't care about*, except in the 
by-now-somewhat-exotic case of 386+387 (where we indeed can't use it 
once user code has touched the FPU -- but we can fall back to 0x80 on 
those, a very small number of systems.)  486+ doesn't use this interface 
under Linux, since Linux uses the proper exception path on those 
processors.  If Compaq had wired up the proper signals on the first 386 
PC motherboards, we wouldn't have cared about it on the 386 either.

	-hpa
--
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/