linux-kernel - Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

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, 08 Dec 2007 15:47:37 -0500
From:	"David P. Reed" <dpreed@...d.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64
 with MCP51 laptops

I am going to do a test on another "unused" port.

However, I realized as I was thinking about this.  0x80 is the 
"diagnostic device" port.  It is not an "unused" port.

Normally, Linux would support a device like the diagnostic device by 
providing a character device, called /dev/post-diagnosis  (for the 
power-on test diagnostic).  That device would reserve port 80 for its 
use, and the driver could be loaded if there was such a device.

Now one possibility is that my laptop contains a diagnostic code device 
that stores all the out's to port 80 (documented only to the designers, 
and kept "secret").   That device may need "clearing" periodically, 
which is perhaps done by the SMM, which is turned off when I go into 
ACPI-on state.  Or maybe it is designed to be cleared only when the 
system boots at the beginning of the BIOS.  What happens when (as 
happens in hwclock's polling of the RTC) thousands of in/out*_p calls 
are made very fast?  Well, perhaps it is not cleared quickly enough, and 
hangs the bus.

The point here is that Linux is NOT using a defined-to-be "unused" 
port.  It IS using the "diagnostic" port, and talking to a diagnostic 
device that *is* used, and may be present.

Just doesn't seem clean to me.

So I'd suggest 2 actions:

1) figure out a better implementation of _p that is "safe" and doesn't 
use questionable heuristics.  udelay seems reasonable because it doesn't 
drive contention on the busses on SMP machines, but perhaps someone has 
a better idea.

2) Start a background task with the maintainers of drivers to clean up 
their code regarding these short delays for slow devices (note that it's 
never because the *bus* is slow, but because the *device* is slow.)  
Perhaps this could be helped by "deprecating" the _p calls and 
suggesting an alternative that requires the coder to be precise about 
what the delay is for, and how long it is supposed to be, perhaps on a 
per-machine basis.

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