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: <476DF5BE.5030004@garzik.org>
Date:	Sun, 23 Dec 2007 00:44:30 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Loic Prylli <loic@...i.com>
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

Loic Prylli wrote:
> Supporting extended-conf-space is independant of the issue of using
> mmconf for legacy conf-space.

True.


> There is no real reason to use the same
> method to access both. I have seen several arguments used that were
> implying that, and they all seem really bogus to me. Not only are the
> two ranges (<= 256 and >= 256) structurally independant (you have
> totally independant capabilities lists that are independantly organized
> in each of them), even if they were not there is no consistency issue
> that cannot be dealt with a memory barrier, and the concern about taking
> an extra branch for each pci-conf-space access is also bogus once you
> look at the numbers.
> 
> By possibly using different implementations for the two ranges you avoid
> introducing a new API, you avoid taking risks with mmconf when you don't
> need it. That doesn't preclude using mmconf for everything either if the
> user requests it or based on enough knowledge of the system to be sure
> nothing will break.

Are you prepared to guarantee that freely mixing mmconfig and type1 
config accesses at runtime will always work, on all chipsets?  I'm 
talking about silicon here, not kernel software.

Furthermore, is it best for our users to find problems with mixed config 
accesses -- not at boot time, not at driver load time, but at some 
random time when some random driver does its first extended config space 
access?  IMO, no.  If you are going to fail, failing in a predictable, 
visible way is best.

Failures are more predictable and more consistent with an all-or-none 
scenario.  The all-or-none solutions are the least complex on the 
software side, and far more widely tested than any mixed config access 
scheme.

	Jeff


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