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 15:01:35 +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 14:27, Ingo Molnar wrote:

> * Rene Herman <rene.herman@...il.com> wrote:
> 
>> 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?
> 
> how about doing a known-NOP chipset cycle? For example:
> 
>   inb(PIC_SLAVE_IMR)

An inb is annoying in that it clobbers register al (well, with an inline 
native_io_delay it is at least) and more importantly -- the timing of this 
is going to vary wildly. We really want a register that is effectively 
guaranteed to be unused so that it dies on ISA/LPC or we might get _much_ 
faster PCI only decodes. Even reading port 0x80 itself varies wildly:

http://lkml.org/lkml/2007/12/12/309

> ? I.e. instead of trying to find an unused port, lets try to find a 
> known-used platform register that has no side-effects if read. Use it 
> unconditionally during early bootup and change it to an udelay after 
> calibration. (or use it after early bootup too if a boot parameter has 
> been specified) Or something like this.

It's really going to have to be a known _un_used register and (the write 
direction of) port 0x80 is used exactly for that reason. Port 0xed is a 
known "alternate diagnostic port" used by Phoenix BIOSes at least but Peter 
Anvin reported trouble with that one -- probably for the outb direction but 
assuming that means something was in fact responding, we'd have the same 
timing problem.

I believe we have two "good" options:

1) port 0xed was tested by the current reporter and found to be safe (and 
provide slow enough timing). If DMI  based quirk hacks are available soon 
enough we can switch 0x80 to 0xed based on it. Are they?

2) the thing I posted in the message replied to where immediately after 
tsc_init() (which is before the PIT init) we switch to udelay() if we have a 
TSC which is ofcourse anything modern.

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/