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] [day] [month] [year] [list]

Date:	Mon, 17 Dec 2007 16:27:16 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Pavel Machek <pavel@....cz>,
	"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>
Subject: Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80
	on some AMD64x2 laptops, etc.


* Robert Hancock <hancockr@...w.ca> wrote:

>> unfortunately this hack's side-effects are mis-used by an unknown 
>> number of drivers to mask PCI posting bugs. We want to figure out 
>> those bugs (safely and carefully) and we want to remove this hack 
>> from modern machines that dont need it. Doing anything else would be 
>> superstition.
>
> Are there any such examples known of such drivers? It doesn't seem to 
> make much sense.. PCI IO writes are not posted on any known system 
> (the spec allows them to be posted in the host bus bridge, but if they 
> were they could only be flushed by a read, not a write) and PCI MMIO 
> writes are only guaranteed to flush by doing a read from that device, 
> not by other random port accesses. I suppose using the _p versions of 
> port accesses might happen to mask such problems on certain machines..

yeah, that's the fear - that timing sensitivities or outright races are 
hidden via _p() uses. It's a bit like the BKL - nobody really knows why 
it's still needed in some places but there's "fear" that "stuff might 
break" so removal is very slow. So we should get rid of all _p() uses, 
by either removing them (concluding that the _p() was not needed), or by 
adding in an udelay(2) (documenting that the device indeed relies on the 
delay from the host side) or by adding whatever posting/flushing is 
needed. That will gradually reduce the amount of code that uses _p() 
methods, and will improve the quality of the kernel.

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