linux-kernel - Re: PCI: Fix boot-time hang on G31/G33 PC

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: <20070927183129.A17565@jurassic.park.msu.ru>
Date:	Thu, 27 Sep 2007 18:31:29 +0400
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Jesse Barnes <jesse.barnes@...el.com>
Cc:	Greg KH <greg@...ah.com>, linux-pci@...ey.karlin.mff.cuni.cz,
	Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org,
	Robert Hancock <hancockr@...w.ca>
Subject: Re: PCI: Fix boot-time hang on G31/G33 PC

On Wed, Sep 26, 2007 at 03:20:40PM -0700, Jesse Barnes wrote:
> Ivan, your concern is about disabling things like interrupt controllers 
> and power management chips during probe right?  You're right that doing 
> that could cause problems if we get and interrupt or PMU event at just 
> the wrong time, but that could just as easily happen if decode was 
> still enabled but the BAR had a bogus address programmed (as it would 
> during probing).

Yes, nobody is arguing that moving the BAR around is unsafe, but generally
it's the less of two evils.

The major problem here is that with IO and MEM bits cleared in the command
register you disable *all* address decoders on the device, not just ranges
that have respective BARs. At least this behaviour is required by PCI spec.
Examples:
- legacy VGA IO and memory (no corresponding BARs);
- base/limit registers of P2P bridge;
- PMU and SMBus registers (sort of normal BARs, but hidden elsewhere
  in the config space);
- IDE legacy mode registers;
- IO-APIC registers (typically sort of read-only BAR).

For all of these address ranges our current BAR probe is effectively
a no-op, but disable/re-enable clearly isn't.

> Ultimately, I don't care much one way or another as long as we can get 
> the desktop platforms fixed somehow.  I think disabling decode is the 
> most correct way of doing this, but I'm open to other solutions (this 
> is the only patch I've seen though that's been tested to solve the 
> problem).

There are two other solutions: one is to disable decode selectively,
only on devices or systems where it's necessary and known to be safe.
I've posted a patch which introduces "disable_while_probe" pci_dev field
for that purpose.
Another one is to delay mmconfig probe until after the PCI probe is done,
as Matthew suggested, and Robert confirmed that it's feasible.

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