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: <alpine.LFD.0.9999.0712230925240.21557@woody.linux-foundation.org>
Date:	Sun, 23 Dec 2007 09:32:28 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
cc:	Jeff Garzik <jeff@...zik.org>, Loic Prylli <loic@...i.com>,
	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 Sun, 23 Dec 2007, Ivan Kokshaysky wrote:
> 
> This is a result of all-or-none approach, as mmconfig is fundamentally
> unsafe until after PCI init is done.

Yes. One of the things I want to have happen (and which 
"pci_enable_mmconf()" would do automatically) is that we always probe 
using conf1 cycles in any machine where conf1 works at all. 

Then, some late PCI quirk or some per-device quirk (or driver) can decide 
to enable mmconf later, and that avoids the current nightmare with the 
whole resource ordering. 

Of course, if there really are machines that have somehow disabled conf1 
accesses, we'd have to use mmconfig early, but that should automatically 
be handled by the PCI config probing stuff (ie we already test whether 
conf1 accesses seem to work, and would fall back on alternate config 
cycle accesses if conf1 looks broken).

Right now, the check that MMCONF space has to be in e820-reserved memory 
space protects us from *most* of the probe-time problems, but that's also 
obviously the check that actually means that MMCONF isn't actually used on 
the vast majority of machines out there.

(For example: I have three machines that I know have working MMCONF. On 
only one of theose does Linux actually even enable MMCONF accesses, 
because on the two other ones the BIOSes do the crazy "put it in some 
space that is reserved by PnP crap later", so we actually refuse to touch 
it. So at least in my limited environment, we hardly get any MMCONFIG test 
coverage, exactly because we have to be so totally anal about not enabling 
it early, because we cannot guarantee that it's not clashing with anything 
else).

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