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:	Sat, 12 Jan 2008 23:01:54 -0700
From:	Matthew Wilcox <matthew@....cx>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
Cc:	Loic Prylli <loic@...i.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Daniel Barkalow <barkalow@...ervon.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Kai Ruhnau <kai@...getaschen.dyndns.org>,
	Robert Hancock <hancockr@...w.ca>,
	Jeff Garzik <jeff@...zik.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	gregkh@...e.de, linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Martin Mares <mj@....cz>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in

On Sat, Dec 29, 2007 at 12:12:19AM +0300, Ivan Kokshaysky wrote:
> On Fri, Dec 28, 2007 at 12:40:53PM -0500, Loic Prylli wrote:
> > One thing that could be changed in pci_cfg_space_size() is to avoid
> > making a special case for PCI-X 266MHz/533Mhz (assume cfg_size == 256
> > for such devices too, reserve extended cfg-space for pci-express
> > devices). There is good reasons to think no such PCI-X 266Mhz/533 device
> > will ever have an extended-space (no capability IDs was ever defined in
> > the PCI-X 2.0 spec, no new revision is planned). Such a check would
> > avoid the possibility of trying extended-conf-space access for PCI-X 2.0
> > devices behind a amd-8132 or similar (such accesses would just returnd
> > -1, but there was some objections raised about doing anything like that
> > other than at initialization time, even if there is ample reasons to
> > argue it would be harmless).
> 
> I agree, we should remove it. IIRC, this PCI-X check was written
> long ago with some draft (not a final spec) in hands. Matthew?

I have what I believe to be the released version of PCI-X 2.0a (July
22, 2003).  It is quite clear that Mode 2 devices (ie those running at
266MHz or 533MHz) are required to support all 4096 bytes of extended
config space.

More to the point, I don't think we have any bug reports suggesting that
PCI-X Mode 2 devices/bridges have any problems.  There are relatively
few of them in existance, and my impression is that PCI-X2 is only being
implemented on server-class machines.  'Consumer grade' equipment is
where all the problems lie anyway.

While the PCI-X 2.0a spec does not define any Extended Capability IDs,
it simply states that "This field is a PCI-SIG defined ID number that
indicates the nature and format of the Extended Capabilities List item".
The PCIe spec does define Extended Capability IDs, and I would think
it's entirely appropriate to use the same IDs for PCI-X Mode 2 devices.

So I don't believe any change in this area is appropriate.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/