linux-kernel - Re: Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver

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: <47BC89F5.90305@reed.com>
Date:	Wed, 20 Feb 2008 15:13:41 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Rene Herman <rene.herman@...access.nl>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Dmitry Torokhov <dtor_core@...ritech.net>,
	linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] x86: use explicit timing delay for
 pit accesses in kernel and pcspkr driver

Actually, disparaging things as "one idiotic system" doesn't seem like a 
long-term thoughtful process - it's not even accurate.  There are more 
such systems that are running code today than the total number of 486 
systems ever manufactured.  The production rate is $1M/month.

a) ENE chips are "documented" to receive port 80, and also it is the 
case that modern chipsets will happily diagnose writes to non-existent 
ports as MCE's.   Using side effects that depend on non-existent ports 
just creates a brittle failure mode down the road.  And it's not just 
post ACPI "initialization".   The pcspkr use of port 80 caused solid 
freezes if you typed "tab" to complete a command line and there were 
more than one choice, leading to beeps.

b) sad to say, Linux is not what hardware vendors use as the system that 
their BIOSes MUST work with.  That's Windows, and Windows, whether we 
like it or not does not require hardware vendors to stay away from port 80.

IMHO, calling something "idiotic" is hardly evidence-based decision 
making.   Maybe you love to hate Microsoft, but until Intel writes an 
architecture standard that says explicitly that a "standard PC" must not 
use port 80 for any peripheral, the port 80 thing is folklore, and one 
that is solely Linux-defined.

Rene Herman wrote:
> On 20-02-08 18:05, H. Peter Anvin wrote:
>  
>> Rene Herman wrote:
>>>
>>> _Something_ like this would seem to be the only remaining option. It 
>>> seems fairly unuseful to #ifdef around that switch statement for 
>>> kernels without support for the earlier families, but if you insist...
>>>
>>
>> "Only remaining option" other than the one we've had all along.  Even 
>> on the one idiotic set of systems which break, it only breaks 
>> post-ACPI intialization, IIRC.
>
> Linus vetoed the DMI switch.
>
> 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/