linux-kernel - Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

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:	Thu, 27 Dec 2007 09:52:44 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de,
	inux-pci@...ey.karlin.mff.cuni.cz,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Mares <mj@....cz>, Matthew Wilcox <matthew@....cx>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in

On Thu, 27 Dec 2007, Jeff Garzik wrote:
> 
> 2) [non-minor] hmmmm.
> 
> 	[jgarzik@...e ~]$ lspci -n | wc -l
> 	23
> 
> So I would have to perform 23 sysfs twiddles, before I could obtain a full and
> unabridged 'lspci -vvvxxx'?

Or you force it on with "pci=mmconfig" or something at boot-time.

But yes. The *fact* is that MMCONFIG has not just been globally broken, 
but broken on a per-device basis. I don't know why (and quite frankly, I 
doubt anybody does), but the PCI device ID corruption happened only for a 
specific set of devices.

Whether it was a timing issue with particular devices or whether it was a 
timing issue with some particular bridge (and could affect any devices 
behind that bridge), who knows... It almost certainly was brought on by a 
borderline (or broken) northbridge, but it apparently only affected 
specific devices - which makes me suspect that it wasn't *entirely* due to 
just the northbridge, and it was a combination of things.

I don't understand why you cannot seem to accept that per-device thing, in 
the face of clear data that yes, it really *is* per-device. Not to mention 
the fact that the way MMIO config setups work, you may well have entire 
buses that simply aren't accessible with MMIO config at all (because the 
MMIO config window is not large enough).

Furthermore, please accept the fact that of those 23 devices, exactly 
*none* will actually care. So yes, you'd have to enable it manually for 
those individual devices, but that's only if you want to do something 
totally pointless in the first place.

So stop this totally inane "it has to be global" crap. It doesn't have to 
be global at all, and we have hard data showing that it really SHOULD NOT 
be a global flag.

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