linux-kernel - Re: [PATCH 03/15] PCI: mvebu: Check that PCI bridge specified in DT has function number zero

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: <20220107210902.GA403155@bhelgaas>
Date:   Fri, 7 Jan 2022 15:09:02 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Marek Behún <kabel@...nel.org>,
        linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 03/15] PCI: mvebu: Check that PCI bridge specified in DT
 has function number zero

On Fri, Jan 07, 2022 at 07:18:19PM +0100, Pali Rohár wrote:
> On Friday 07 January 2022 12:15:12 Bjorn Helgaas wrote:
> > On Thu, Nov 25, 2021 at 01:45:53PM +0100, Pali Rohár wrote:
> > > Driver cannot handle PCI bridges at non-zero function address. So add
> > > appropriate check. Currently all in-tree kernel DTS files set PCI bridge
> > > function to zero.
> > 
> > Why can the driver not handle bridges at non-zero function addresses?
> > The PCI spec allows that, doesn't it?  Is this a hardware limitation?
> 
> It is software / kernel limitation.
> 
> Because this bridge is virtual, emulated by pci-bridge-emul.c driver and
> this driver can emulate only single function PCI-to-PCI bridge device.

That's weird.  Why does pci-bridge-emul.c care about the function
number?  Or maybe you're saying that pci-mvebu.c isn't smart enough to
build an emulated bridge at a non-zero function?  Or, since this is
emulated, maybe there's just no *reason* to ever use a non-zero
function?

It would really be nice to have the commit log and maybe even a
comment allude to what's going on here .  Otherwise this check sort of
dangles without having an obvious reason for existence.

Does this issue also affect pci-aardvark.c (which looks like the only
other user of pci_bridge_emul_init())?

> > > Signed-off-by: Pali Rohár <pali@...nel.org>
> > > Cc: stable@...r.kernel.org
> > > ---
> > >  drivers/pci/controller/pci-mvebu.c | 5 +++++
> > >  1 file changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
> > > index 6197f7e7c317..08274132cdfb 100644
> > > --- a/drivers/pci/controller/pci-mvebu.c
> > > +++ b/drivers/pci/controller/pci-mvebu.c
> > > @@ -864,6 +864,11 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
> > >  	port->devfn = of_pci_get_devfn(child);
> > >  	if (port->devfn < 0)
> > >  		goto skip;
> > > +	if (PCI_FUNC(port->devfn) != 0) {
> > > +		dev_err(dev, "%s: invalid function number, must be zero\n",
> > > +			port->name);
> > > +		goto skip;
> > > +	}
> > >  
> > >  	ret = mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_MEM,
> > >  				 &port->mem_target, &port->mem_attr);
> > > -- 
> > > 2.20.1
> > >