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 00:09:36 -0500
From:	Loic Prylli <loic@...i.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	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 12/22/2007 11:13 PM, Jeff Garzik wrote:
>
> The facts as they exist today:
>
> 1) Existing 256-byte config space devices have been known put
> capabilities in the high end (>= 0xc8) of config space.
>
> 2) It is legal for PCI-Express to put capabilities anywhere in PCI
> config space, including extended config space.  (I hope our PCI cap
> walking code checks for overruns...)

You make it sound almost as if the capability list that starts in
regular conf-space could cross into extended conf-space >= 256). That's
not true, the capability lists in the regular conf-space and the
extended conf-space are really separate, they use a different structure
for linking (different number of bits to define the capability IDs), a
different starting point, different capability IDs definition tables.
The regular conf-space and the extended conf-space are really independant.

>
> 3) Most new machines ship with PCI-Express devices with extended
> config space.
>
> Therefore it is provable /possible/, and is indeed logical to conclude
> that capabilities in extended config space will follow the same
> pattern that existing hw designers have been following...  but only
> once the current OS's have stable extended-config-space support.
>
> Maybe that day will never come, but it is nonetheless quite possible
> within today's PCI Express spec for this to happen.

I agree with that statement. In fact it is already quite useful today. I
am doing a lot of support activities where extended-conf-space is a must
for troubleshooting. It was important enough for us that we have
user-tools that allows us to access mmconfig-space for pci-express even
on systems that don't advertise a MCFG attribute (as long as the chipset
supports it, we have reverse-engineered the location of the "mmconfig
bar" for a few chipsets including nvidia chipsets, for Intel it is well
documented, and there are couple others).

Loic

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