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]

Message-ID: <477AE225.3070706@keyaccess.nl>
Date:	Wed, 02 Jan 2008 02:00:21 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	Christer Weinigel <christer@...nigel.se>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	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.

On 02-01-08 01:55, Christer Weinigel wrote:

> On Wed, 02 Jan 2008 00:11:54 +0100
> Rene Herman <rene.herman@...access.nl> wrote:
> 
>> Well, on the PIIX it is and I guess on anything where it's _not_
>> fully internal an 0xf0 write wouldn't have any effect on IRQ13...
>>
>> When you earlier mentioned this it seemed 0xed switched on DMI would
>> be good enough, but well.
>>
>> Alan, do you have an opinion on the port 0xf0 write? It should
>> probably still be combined with a replacement/deletion for new
>> machines due to the bus-locking "bad for real-time" thing you
>> mentioned earlier but in the short run it could be a fairly
>> low-impact replacement on anything except a 386+387
> 
> Both 0xed and 0xf0 are mapped to internal functions on the AMD Elan
> SC400 processor.  It is an AMD 486 based system on a chip and since AMD
> just knew that it would never have a math coprocessor, they reused the
> 0xf0-0xf2 range for the PCMCIA controller.  I guess the AMD Elan SC500
> will have similar problems.
> 
> I seem to recall that back when I was working with the Elan SC400
> (sometime around 1998?) there were discussions about finding an
> alternate delay port because outb to 0x80 messed up the debug port.  I
> think the Elan stopped those discussions because just about every port
> on the Elan was reused for some alternate purpose.  

Okay, thanks much. So 0xf0 would be unuseable on 386+387 and AMD Elan SC400 
and could possibly change timing on an unknown number of systems due to not 
being put on the bus.

0x80 only fails for some recent HP laptops instead so it seems there would 
be not enough cause to go with 0xf0 onstead of 0x80 as the default choice; 
if we're quirking around machines anyway it might as well be the DMI based 
quirking currently suggested.

Rene.

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