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]

Message-ID: <alpine.LNX.1.00.0712280036330.13593@iabervon.org>
Date:	Fri, 28 Dec 2007 01:07:09 -0500 (EST)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Kai Ruhnau <kai@...getaschen.dyndns.org>,
	Loic Prylli <loic@...i.com>, Robert Hancock <hancockr@...w.ca>,
	Jeff Garzik <jeff@...zik.org>,
	Arjan van de Ven <arjan@...radead.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>, Matthew Wilcox <matthew@....cx>
Subject: Re: [Patch v2] Make PCI extended config space (MMCONFIG) a driver
 opt-in

On Thu, 27 Dec 2007, Linus Torvalds wrote:

> On Thu, 27 Dec 2007, Daniel Barkalow wrote:
> > 
> > I'd actually bet that the hardware bug is actually that any device that 
> > gives a CRS response the first time will have its Vendor ID appear as 0001 
> > on subsequent mmconfig accesses, which means that it's actually a bus 
> > quirk that probably only affects mmconfig access to something in the 
> > conf1-visible space. The only per-device aspect would be that it uses CRS 
> > (possibly correctly), and that doesn't mean that mmconfig won't be safe in 
> > general for the device, or even that it won't be necessary. Actually, we 
> > already know that per-driver enabling mmconfig is broken: sky2 is one that 
> > wants to opt in but there are also reports of the Vendor ID 0001 bug with 
> > it.
> 
> Actually, having it be a per-device thing would have fixed this particular 
> problem, if only because the device probing would have been done without 
> MMCONFIG (thus avoiding the bug), and then after it has been probed, it 
> wouldn't have mattered if the driver enabled MMCONFIG for the device, 
> since it would now have the right ID in "struct pci_device".
> 
> Sure, subsequent "lspci" users would still be confused, but the kernel 
> itself would never have noticed anything strange.

A bug making lspci see something different from what the kernel sees 
initially sounds to me like a sure way to drive maintainers insane. If 
somebody had a northbridge that also screwed up the rest of the word, and 
a device that a mmconfig-using driver recognized but had problems with, 
the user would be reporting lspci info with 0001:ffff as the device that 
doesn't work.

> Of course, just doing *all* initial probing without MMCONFIG would also 
> have fixed it, which is another thing I advocate (regardless of any 
> per-device setting).

So would always using conf1 for the non-extended space (unless the 
platform only uses mmconfig), or at least for the first 64 bytes. I'd bet 
all the subtle bugs are in the first few words, anyway. (With blatant bugs 
in the rest, of course, where we want to blacklist busses and devices)

	-Daniel
*This .sig left intentionally blank*
--
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/