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:	Thu, 27 Dec 2007 23:27:35 -0500 (EST)
From:	Daniel Barkalow <barkalow@...ervon.org>
To:	Kai Ruhnau <kai@...getaschen.dyndns.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.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, Kai Ruhnau wrote:

> Linus Torvalds wrote:
> > On Thu, 27 Dec 2007, Linus Torvalds wrote:
> >   
> >> Kai, can you try that? Just remove the call to pci_enable_crs() in 
> >> pci_scan_bridge() in drivers/pci/probe.c, and see if mmconfig starts 
> >> working for you?
> >>     
> >
> > We could also make the error handling more permissive, and just check for 
> > the low 16 bits, which is the part that the CRS spec mentions the actual 
> > value for. The whole vendor ID of 0x0001 is mentioned int he CRS spec as 
> > being explicitly chosen exactly because it's invalid.
> >
> > That said, given that we don't actually reap any benefits from CRS support 
> > right now *anyway*, I think the right thing to do is disable it by 
> > default. But it would be interesting to know if this patch makes it work 
> > on those ATI bridges..
> >
> > 		Linus
> >
> > ---
> >  drivers/pci/probe.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 2f75d69..94cd3a4 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -908,7 +908,7 @@ pci_scan_device(struct pci_bus *bus, int devfn)
> >  		return NULL;
> >  
> >  	/* Configuration request Retry Status */
> > -	while (l == 0xffff0001) {
> > +	while ((l & 0xffff) == 0x0001) {
> >  		msleep(delay);
> >  		delay *= 2;
> >  		if (pci_bus_read_config_dword(bus, devfn, PCI_VENDOR_ID, &l)
> 
> That one did not work out so well.
> I reenabled the call to pci_enable_crs() and changed the line as above.
> That resulted in two timeouts (from dmesg):
> 
> [....]
> ACPI: Interpreter enabled
> ACPI: (supports S0 S3 S4 S5)
> ACPI: Using IOACPI for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> Device 0000:01:00.0 not responding
> Device 0000:02:00.0 not responding
> [....]
> 
> Then, the kernel boots up normally except of graphics and network card
> not showing up at all in lspci.

Uh, right. We already know that your northbridge, mmconfig, CRS, and this 
device combine to always return 0001 for the Vendor ID. If we loop on 
getting that, we must time out.

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.

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