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]

Message-ID: <20070917142241.C21399@jurassic.park.msu.ru>
Date:	Mon, 17 Sep 2007 14:22:41 +0400
From:	Ivan Kokshaysky <ink@...assic.park.msu.ru>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
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 Sun, Sep 16, 2007 at 10:01:52PM +0200, Benjamin Herrenschmidt wrote:
> Agreed. I have a similar problem on ppc where it's common to have things
> like the main PIC on a PCI device. Note that another problem is (or at
> least was, i haven't checked recently) the P2P bridge scanning code
> that, in a similar way, can block the path to all devices below it. I
> -do- have a case for example with Apple Xserve G4's where the main Apple
> IO ASIC, which is a PCI device containing the PIC, the power management
> controller, and various low level system control IOs is behind a pair of
> P2P bridges.

I think the P2P probing code is pretty safe now - there are read-only
accesses to the bridge config, unless you request to reassign the bus
numbers. Though it won't be safe anymore with the patch in question.

> One solution for us (PPC) is to enforce those devices and bridges to be
> described in the OF tree, and generalize a bit the code we have for some
> 64 bits machines, that synthetizes the pci_dev's from the OF nodes
> rather than probing. But that's not going to help other archs.

If you can get reliable PCI info from firmware, it should be relatively easy
to avoid at least a bar sizing. You can install an "early" fixup for
PCI_ANY_ID and fill the resource fields of the pci_dev with values obtained
from firmware. Then all we need in probe.c is just to check that the resource
is already non-zero and skip the sizing of respective BAR, if so.

> In fact, that's a problem we also have with
> pci_assign_unassigned_resources() which will happily move things around
> that must not be moved, especially when sitting behind P2P bridges.

It's not supposed to do that. Certainly, there were problems of that sort,
but hopefully they are in the past.

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/