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]

Message-ID: <476DDFEE.3010009@garzik.org>
Date:	Sat, 22 Dec 2007 23:11:26 -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:
> The problem is that it isn't enough that it works on common machines with 
> good hardware. The problem is that we end up chasing insane bugs, wasting 
> peoples valuable time and effort, on those *few* - out of *millions* - of 
> machines that then surprisingly don't work.
> 
> And "surprisingly" is definitely the watch-word. That includes silently 
> just not booting (because the first time anybody tries to do a PCI config 
> cycle access, the machine just locks up) to some really *odd* behaviour 
> (ie everything works fine *except* that reading the PCI card ID from a 
> few cards returns a value of 0x0001 rather than the correct one).

> The fact is, we're currently turning off MMCONFIG very aggressively, 
> exactly because it has caused problems. So most people never even use 
> MMCONFIG when it's enabled, because all of our sanity checks that turn it 
> off again. And it still has caused odd problems.

Yes, I know all this.  I am quite aware of the situation.

My core assertion:  the present situation -- turning off MMCONFIG 
aggressively -- is greatly preferable to adding 
pci_enable_mmconfig_accesses(pdev).

IOW, don't add a new API.  Keep doing what we're doing today.

Today, we have a consistent "all or none" model for mmconfig.  Any 
per-device mmconfig enabling introduces pain and inconsistency, in both 
the kernel and userland.

Users with devices that REQUIRE extended config accesses should buy 
machines with known good mmconfig.  The situation will sort itself out 
from there.  We don't need ugly hacks like 
pci_enable_mmconfig_for_this_device().

	Jeff

(second response, for other paragraphs, following in separate email.  I 
wanted to underscore the core API issue...)

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