linux-kernel - Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.

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:	Sat, 15 Dec 2007 08:58:18 +0100
From:	Rene Herman <rene.herman@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	"David P. Reed" <dpreed@...d.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Rene Herman <rene.herman@...access.nl>,
	Pavel Machek <pavel@....cz>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80
 on some AMD64x2 laptops, etc.

On 15-12-07 08:43, Ingo Molnar wrote:

> * H. Peter Anvin <hpa@...or.com> wrote:
> 
>> I believe this will suffer from the issue that was raised: this will 
>> use udelay() long before loop calibration (and no, we can't just "be 
>> conservative" since there is no "conservative" value we can use.)
>>
>> Worse, I suspect that at least the PIT, which may need to be used for 
>> udelay calibration, is one of the devices that may be affected.  I 
>> have seen the Verilog for a contemporary chipset, and it can only 
>> access the PIT once per microsecond -- this actually has to do with 
>> the definition of the PIT; some of the PIT operations are ill-defined 
>> if allowed at a higher frequency than the PIT clock.
> 
> i think the native_io_delay() in quirks.c signals the obvious solution: 
> a DMI (or otherwise) driven quirk that activates a port 0x80 based delay 
> on such boards. Combined with an iodelay=port80 boot option as well 
> perhaps, just in case someone hits a system that is not blacklisted yet. 
> This way such crazy broken hardware can be mapped correctly - like we 
> map such quirks in every other case. Perhaps even do this workaround on 
> the PIT driver level. Instead of perpetuating the superstition of port 
> 80 forever.

The issue is -- how do you safely replace the outb pre-loops_per_jiffy 
calibration? I'm currently running with the attached hack (not submitted, 
only for 32-bit and discussion) the idea of which might be the best we can do?

(And the broken is the hardware that can't take writes to port 0x80, not the 
other way around. It's a well-known legacy PC thing).

Rene.


View attachment "native_io_delay-switch.diff" of type "text/plain" (1913 bytes)