linux-kernel - Re: [PATCH]PCI:disable resource decode in PCI BAR detection

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:	Fri, 14 Sep 2007 15:14:01 +0400
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	Greg KH <gregkh@...e.de>, Matthew Wilcox <matthew@....cx>,
	Shaohua Li <shaohua.li@...el.com>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-pci <linux-pci@...ey.karlin.mff.cuni.cz>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH]PCI:disable resource decode in PCI BAR detection

On Thu, Sep 13, 2007 at 09:32:42PM -0600, Robert Hancock wrote:
> Disabling the BAR decoding does not mean disabling the device (aside 
> from the one  group of host bridge that apparently disables CPU to RAM 
> access, whose designers were apparently on crack when they read the PCI 
> spec and which is why we don't disable the decode on host bridges). 
> There really is no other sane way to do it.

Disabling IO and MEM decode effectively disables device as a PCI target.
Worse, it's often not just BARs that get disabled, but some non-standard
or hidden address ranges as well. Host bridges are just one common
example, there is a lot of other insane hardware, more than one could
expect.
BTW, the way how the internal address decode works on these latest Intel
whippets doesn't look sane either. ;-)

> If we do encounter other devices that choke on having the BAR disabled 
> during probing then we can add additional quirk logic, but we haven't 
> run into anything like that yet.

As Greg said, the main point is "no regression".

Folks, can you check if the patch below helps?

Ivan.

--- 2.6.23-rc6-git4/include/linux/pci.h	2007-09-12 17:22:57.000000000 +0400
+++ linux/include/linux/pci.h	2007-09-14 10:26:29.000000000 +0400
@@ -183,6 +183,7 @@ struct pci_dev {
 	unsigned int 	msi_enabled:1;
 	unsigned int	msix_enabled:1;
 	unsigned int	is_managed:1;
+	unsigned int	disable_while_probe:1; /* Probe BARs with IO and MMIO turned off */
 	atomic_t	enable_cnt;	/* pci_enable_device has been called */
 
 	u32		saved_config_space[16]; /* config space saved at suspend time */
--- 2.6.23-rc6-git4/arch/i386/pci/fixup.c	2007-09-12 17:22:55.000000000 +0400
+++ linux/arch/i386/pci/fixup.c	2007-09-14 14:43:13.000000000 +0400
@@ -444,3 +444,21 @@ static void __devinit pci_siemens_interr
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_SIEMENS, 0x0015,
 			  pci_siemens_interrupt_controller);
+
+/*
+ * Work around apparent quirk in internal address decoding on
+ * some Intel chipsets (G31, G33, Q965 etc.): 
+ * when some MMIO address range of integrated peripheral overlaps
+ * mmconfig area, mmconfig accesses are blocked. This can happen
+ * when we size the BAR writing all ones to it.
+ * In practice, only integrated graphics controller has MMIO range
+ * large enough (BAR2, 256Mb) to cause a trouble, so we disable
+ * address decoders just on that function during PCI BAR probe.
+ */
+static void __devinit pci_intel_mmconfig(struct pci_dev *dev)
+{
+	if ((dev->class >> 8) == PCI_CLASS_DISPLAY_VGA &&
+	    pci_domain_nr(dev->bus) == 0 && dev->bus->number == 0)
+		dev->disable_while_probe = 1;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_intel_mmconfig);
--- 2.6.23-rc6-git4/drivers/pci/probe.c	2007-09-14 00:35:47.000000000 +0400
+++ linux/drivers/pci/probe.c	2007-09-14 10:27:45.000000000 +0400
@@ -185,6 +185,13 @@ static void pci_read_bases(struct pci_de
 	unsigned int pos, reg, next;
 	u32 l, sz;
 	struct resource *res;
+	u16 cmd, orig_cmd;
+
+	if (dev->disable_while_probe) {
+		pci_read_config_word(dev, PCI_COMMAND, &orig_cmd);
+		cmd |= orig_cmd & ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
+		pci_write_config_word(dev, PCI_COMMAND, cmd);
+	}
 
 	for(pos=0; pos<howmany; pos = next) {
 		u64 l64;
@@ -283,6 +290,8 @@ static void pci_read_bases(struct pci_de
 			}
 		}
 	}
+	if (dev->disable_while_probe)
+		pci_write_config_word(dev, PCI_COMMAND, orig_cmd);
 }
 
 void pci_read_bridge_bases(struct pci_bus *child)
-
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/