linux-kernel - [PATCH] x86: 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]

Message-ID: <476462BE.3030701@gmail.com>
Date:	Sun, 16 Dec 2007 00:26:54 +0100
From:	Rene Herman <rene.herman@...il.com>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Paul Rolland <rol@...917.net>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@....cz>, Ingo Molnar <mingo@...e.hu>,
	"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>, rol@...be.net
Subject: [PATCH] x86: fix problems due to use of "outb" to port 80 on some
 AMD64x2 laptops, etc.

On 15-12-07 21:27, H. Peter Anvin wrote:

> Rene Herman wrote:
>>
>> Yes, just posted a Patch-For-Comments that switches on the 
>> availability of a TSC (tsc_init sets tsc_disable also for 
>> !cpu_has_tsc) which would mean that only really old stuff would be 
>> using the outb still. A TSC is really all we need to have a sensible 
>> udelay().
> 
> Uhm, no.  You have no clue what the speed of the TSC is until you have 
> been able to calibrate it against a fixed timesource - like the PIT.

Yes. Hnng. Okay, this is going nowhere in a hurry, so back to the very first 
suggestion in this thread. How about this? This allows to switch from port 
0x80 to port 0xed based on DMI.

David: I plugged in my own DMI values for testing, but obviously yours are 
needed. The values that are needed are retrieved by the "dmidecode" program 
which you will probably have installed (it might be in an sbin directory) or 
will be able to install through whatever package manager you use.

dmidecode -s baseboard-manufacturer
dmidecode -s baseboard-product-name

are the values you should plug into the .matches field in the dmi_system_id 
struct in this. It would be great if you could do that, test, and post back 
with those values. .ident should be a nice human name.

It's been tested on x86-32 and seems to work fine. It's not been tested on 
x86-64 but seems to stand a fair chance of working similarly.

It ofcourse remains possible to switch to a udelay() based method later on 
anyways but with all the pre-calibratin trouble, this might be the lowest 
risk method in the short run.

This is partly based on previous patches by Pavel Machek and David P. Reed.

I hope this is considered half-way correct/sane (note by the way that it's 
not a good idea to switch a "native_io_delay_port" value since plugging in a 
variable port would clobber register dx for every outb_p, which would then 
have to be reloaded for the next outb again). Comments appreciated.

Signed-off-by: Rene Herman <rene.herman@...il.com>

  arch/x86/boot/compressed/misc_32.c |    8 ++---
  arch/x86/boot/compressed/misc_64.c |    8 ++---
  arch/x86/kernel/Makefile_32        |    2 -
  arch/x86/kernel/Makefile_64        |    2 -
  arch/x86/kernel/io_delay.c         |   53 
+++++++++++++++++++++++++++++++++++++
  arch/x86/kernel/setup_32.c         |    2 +
  arch/x86/kernel/setup_64.c         |    2 +
  include/asm-x86/io_32.h            |   17 ++---------
  include/asm-x86/io_64.h            |   23 ++++++----------

View attachment "dmi-io_delay.diff" of type "text/plain" (7134 bytes)