netdev - Re: [PATCH pci] PCI: don't skip probing entire device if first fn OF node has status = "disabled"

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: Wed, 31 May 2023 01:04:36 +0300
From: Vladimir Oltean <vladimir.oltean@....com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: linux-pci@...r.kernel.org, netdev@...r.kernel.org,
	Bjorn Helgaas <bhelgaas@...gle.com>, Rob Herring <robh@...nel.org>,
	Claudiu Manoil <claudiu.manoil@....com>,
	Michael Walle <michael@...le.cc>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH pci] PCI: don't skip probing entire device if first fn OF
 node has status = "disabled"

On Tue, May 30, 2023 at 04:58:55PM -0500, Bjorn Helgaas wrote:
> Can you write this description in terms of PCI topology?  The
> nitty-gritty SERDES details are not relevant at this level, except to
> say that Function 0 is present in some cases but not others, and when
> it is not present, *other* functions may be present.

No. It is to say that within the device, all PCIe functions (including 0)
are always available and have the same number, but depending on SERDES
configuration, their PCIe presence might be practically useful or not.
So that's how function 0 may end having status = "disabled" in the
device tree.

> Sigh.  Per spec (PCIe r6.0, sec 7.5.1.1.9), software is not permitted
> to probe for Functions other than 0 unless "explicitly indicated by
> another mechanism, such as an ARI or SR-IOV Capability."
> 
> Does it "work" to probe when the spec prohibits it?  Probably.  Does
> it lead to some breakage elsewhere eventually?  Quite possibly.  They
> didn't put "software must not probe" in the spec just to make
> enumeration faster.
> 
> So I'm a little grumpy about further complicating this already messy
> path just to accommodate a new non-compliant SoC.  Everybody pays the
> price of understanding all this stuff, and it doesn't seem in balance.
> 
> Can you take advantage of some existing mechanism like
> PCI_SCAN_ALL_PCIE_DEVS or hypervisor_isolated_pci_functions() (which
> could be renamed and made more general)?

Not responding yet to the rest of the email since it's not clear to me
that you've understood function 0 is absolutely present and responds
to all config space accesses - it's just disabled in the device tree
because the user doesn't have something useful to do with it.