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:	Sun, 23 Dec 2007 07:43:37 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	linux-kernel@...r.kernel.org, gregkh@...e.de,
	linux-pci@...ey.karlin.mff.cuni.cz
Subject: Re: [patch] Make MMCONFIG space (extended PCI config space) a
	driver opt-in issue


On Sat, 2007-12-22 at 04:31 -0800, Arjan van de Ven wrote:
> Hi,
> 
> Linus really wants the extended (4Kb) PCI configuration space (using MCFG acpi table etc) to be opt-in, since there's many issues with it and most drivers don't even use/need it. The idea behind opt-in is that if you don't use it, you don't get to suffer the bugs...
> 
> Booted on my 64 bit test machine; sadly it has a defunct BIOS that doesn't have a working MCFG.
> 
> 
> From: Arjan van de Ven <arjan@...ux.intel.com>
> Subject: Make MMCONFIG space a driver opt-in
> 
> There are many issues with using the extended PCI configuration space 
> (CPU, Chipset and most of all BIOS bugs). This while the vast majority of drivers
> and devices don't even use/need to use the memory mapped access methods since they
> don't use the config space beyond the traditional 256 bytes.
> 
> This patch makes accessing the extended config space a driver choice, via the
> 
> pci_enable_ext_config(pdev)
> 
> API function; drivers that want/need the extended configuration space should call this.
> (a separate patch will be posted to add this function call to the driver that uses this)

That doesn't look like the right approach to me.

The extended config space is generally used by PCI capabilities. So you
end up in a situation where part of the capabilities will be invisible
until somebody calls your new API, which might affect generic code in
some cases beyond simply what a driver is supposed to do.

I think best is to have your low level config ops switch between
indirect and MM depending on the requested register offset.

Ben.


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