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: <20071224154726.GA2505@jurassic.park.msu.ru>
Date:	Mon, 24 Dec 2007 18:47:26 +0300
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	Loic Prylli <loic@...i.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

On Mon, Dec 24, 2007 at 02:22:10AM -0500, Jeff Garzik wrote:
> The phrase "all or none" specifically describes the current practice in 
> arch/x86/pci/mmconfig_{32,64}.c whereby a PCI bus always has one, and only 
> one, access method.
>
> So the problems you describe are unrelated to "all or none" as I was 
> describing it.

Ok. So a correct description would be "one or another but not both".

>> The mixed access that Loic proposes allows to avoid these boot problems
>> just for free.
>
> False.  If you have overlapping areas, then clearly it is board-dependent 
> (undefined) what happens -- you might trigger an mmconfig access by 
> writel() to your PCI device's MMIO BAR space.

You're not allowed to access MMIO defined by BARs before the PCI setup
process is finished because a) decode of the BAR might be disabled for
a number of reasons and b) the BAR may contain any random value.
So you never know *what* you're accessing until after
pci_assign_unassigned_resources() and without pci_enable_device().

> Consider, too, what the current code in arch/x86/pci/mmconfig_{32,64}.c 
> does:  it uses the range BIOS told to use for mmconfig, no more no less.

Incorrect. It does reads mcfg info directly from hardware for two Intel
bridges (should be much more - mmconfig BAR is well documented for all
Intel (and AMD, I guess) chipsets.

> Clearly many early mmconfig BIOSes have buggy resource allocation... Thus 
> if mmconfig is not known working on a system, turn it off 100% for all 
> buses.  End of story.

Direct hardware support for more chipsets would certainly help here.

>> Systems that have both non-mmconf PCI(X) and mmconf PCI-E
>> domains could be handled almost for free as well.
>
> The existing code in arch/x86/pci/mmconfig_{32,64}.c today handles mixing 
> of PCI-E and PCI-X just fine.  As noted above, its done on a per-bus and 
> per-segment basis today.

With mixed access unreachable_devices() and related stuff could have gone.

> The proposed API adds code, so I don't see how it simplifies things.

See above.

> The current approach is quite clean anyway:
>
> 1) "raw_pci_ops" points to a single set of PCI config accessors.
> 2) For mmconfig, if the BIOS did not tell us to use mmconfig with a given 
> PCI bus, fall back to type1 accesses.

But it doesn't work on systems where [basically working] mmconfig causes
boot problems because it's enabled too early.

> I agree with the function as noted in response to Linus's "Sound ok with 
> this plan?" email.  But note -- users and developers also need to access 
> extended config space, even if driver did not request it.  Even if there is 
> no driver at all.

There *is* a driver - pci-sysfs.c.

> Otherwise the value of "lspci -vvvxxx" debugging reports from users is 
> diminished.

Not at all. I don't see any reason to change the userspace API -
just make pci-sysfs.c:pci_{read,write}_config to request extended space
if (off + count > 256).

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