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

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, 22 Dec 2007 20:26:55 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de,
	linux-pci@...ey.karlin.mff.cuni.cz,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a driver
 opt-in issue

Linus Torvalds wrote:
> 
> On Sat, 22 Dec 2007, Arjan van de Ven wrote:
> 
>> On Sat, 22 Dec 2007 09:20:06 -0500
>> Jeff Garzik <jeff@...zik.org> wrote:
>>> Yuck.  And, Linus is just being silly.  Wait a year then turn on 
>>> MMCONFIG :)  It took PCI MSI a while to mature, but is finally
>>> getting there.
> 
> That _really_ doesn't work.
> 
> Old machines don't go away. We can't just say "wait a year and turn on 
> MMCONFIG", because all the broken machines WILL STILL EXIST.

You are reinforcing my point :)

The exact same thing can be said for PCI MSI machines that are broken. 
Outside of Intel machines, early PCI MSI life was yucky and broken. 
Time passed, we got a handle on the problem set, we quirked that 
problematic set of systems, and life moved on.

And these days, we are benefitting from that -- most new hardware is 
MSI-capable if not MSIX-capable, and we are turning that on.

Some day in the future MSI-only (no INTX) hardware will ship in volume, 
and we will already be adequately prepared for that day.

But here the two items diverge:  PCI MSI _can_ be an _option_ for most 
hardware, hence pci_enable_msi().  But the same cannot be said for 
MMCONFIG, for reasons outlined below...

>> Do you hate the name or the concept? I'm certainly open for a better name.... 
> 
> Just make it so. The name is fine, the concept is unavoidable. The people 
> who complain are whiners that haven't ever had to deal with the fact that 
> there are broken machines around. 
> 
> For example, right now Jeff never sees the problem, because when MMCONFIG 
> doesn't work, it's never his problem - nothing in the machine works. But 
> if he has to add a "pci_enable_mmconfig()" to the drivers he maintains, he 
> sees it as a _new_ problem, so he obviously thinks it's stupid: he was 
> never impacted by the issues it fixed!

I forcibly turn on mmconfig on all my machines, and monitor lkml, to 
make sure I'm aware of the extent of the problem -- and the extent of 
peoples' exaggeration of this problem.

> So it's natural for Jeff to not like it, but that doesn't make Jeff right 
> in this case. It just means that Jeff never had to worry about it before, 
> because as long as MMCONFIG wasn't per-driver, the problems it caused were 
> never *his* problems. But that doesn't make them less of a problem.

Doing it at the driver level fundamentally doesn't work:

Regardless of whether a driver is loaded or not, you may NEED to see 
extended capabilities.  The system may NEED to see those capabilities 
just to parse them for sane operation.

And pciutils should be able to see all of config space, not just the 
Linus-sanitized portion of it.  This will make debugging more difficult, 
for example, because "lspci -vvvxxx" will not be giving me the full 
"before" and "after" snapshots I need from users, to see if anything 
changes based on <some hardware poking during debugging>.

I know when you look you see all sorts of brokenness.  But you and I 
both know that will pass, with time.  If its buggy, turn it off.  If 
not, turn it on.  All these hardware makers are paying attention and 
fixing errata; evidence of forward progress in that regard has already 
appeared even.

Finally, this introduces a new per-device model for PCI config space 
accesses, something we have NEVER done before.  PCI config space should 
always be all or none.  If MMCONFIG is fucked, just turn it off completely.

Having to deal with NEW issues brought on by this NEW per-device config 
space access model is stupid-by-design.  Always-off is better than 
changing the access model from global to per-device.

It is even MORE unlikely that hardware makers test the "mmconfig over 
here, type1 over there" mixed accesses.  Linux should not go down that road.

Always-off is better than mixed access models.

	Jeff

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