linux-kernel - Re: 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:	Wed, 09 Jan 2008 09:42:19 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Christer Weinigel <christer@...nigel.se>
CC:	Zachary Amsden <zach@...are.com>, Avi Kivity <avi@...amnet.com>,
	Ondrej Zary <linux@...nbow-software.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rene Herman <rene.herman@...access.nl>,
	Bodo Eggert <7eggert@....de>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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 <rol@...be.net>
Subject: Re: Re: [PATCH] x86: provide a DMI based port 0x80
 I/O delay override.

Christer Weinigel wrote:
>
> Did I miss anyting?
>
>   
Nothing that seems *crucial* going forward for Linux.  The fate of
"legacy machines" is really important to get right.

I have a small suggestion in mind that might be helpful in the future:
the  "motherboard resources" discovered as PNP0C02 devices in their _CRS
settings in ACPI during ACPI PnP startup should be reserved (or
checked), and any drivers that still use port 80 implicitly should
reserve that port.

This may be too late in the boot process to make a decision not to use 
port 80, and it
doesn't help decide a strategy to use an alternate port (0xED happens to
"work" on the dv9000 machines in the sense that it generates a bus
timeout on LPC, but there is no guarantee that 0xED is free on any 
particular motherboard, and "unusedness" is not declared in any 
BIOS/ACPI tables) or to use a udelay-based iodelay (but there is nothing 
in the BIOS tables that suggest the right delays for various I/O ports 
if any modern parts need them...which I question, but can't prove a 
negative in general).

However, doing the reservations on such resources could generate a 
warning that would help diagnose new current and future
designs including devices like the ENE KB3920 that have a port that is
defaulted to port 80 and routed to the EC for functions that the 
firmware and ACPI can agree to do.  Or any other ports used in new ways 
and properly notified to the OS via the now-standard Wintel BIOS functions.

I don't know if /proc/ioports is being maintained, but the fact that it
doesn't contain all of those PNP0C02 resources known on my machine seems 
to be a bug - which I am happy to code a patch or two for as a 
contribution back to Linux, if it isn't on the way out as the /sys 
hierarchy does a better job.
/sys/bus/pnp/... does get built properly and has port 80 described
properly - not as a DMA port, but as a port in use by device 05:00, 
which is the motherboard resource catchall.  Thus the patch would be small.

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