linux-kernel - Re: [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver

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: <CACoXjcmuVZbAQcHyunxu4DaY3Wew2tttydWsSmneYiUf73dRow@mail.gmail.com>
Date:	Mon, 22 Sep 2014 15:59:35 -0700
From:	Tanmay Inamdar <tinamdar@....com>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>, Arnd Bergmann <arnd@...db.de>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Rob Landley <rob@...dley.net>,
	Liviu Dudau <liviu.dudau@....com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	patches <patches@....com>, Jon Masters <jcm@...hat.com>
Subject: Re: [PATCH v9 1/4] pci:host: APM X-Gene PCIe host controller driver

On Mon, Sep 22, 2014 at 3:27 PM, Jason Gunthorpe
<jgunthorpe@...idianresearch.com> wrote:
> On Mon, Sep 22, 2014 at 04:09:03PM -0600, Bjorn Helgaas wrote:
>> On Mon, Sep 22, 2014 at 3:33 PM, Tanmay Inamdar <tinamdar@....com> wrote:
>>
>> >>> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
>> >>> +{
>> >>> +     int i;
>> >>> +
>> >>> +     /* Hide the PCI host BARs from the kernel as their content doesn't
>> >>> +      * fit well in the resource management
>> >>> +      */
>> >>
>> >> This needs a better explanation than "doesn't fit well."
>> >>
>> >> I *think* you're probably talking about something similar to the MVEBU
>> >> devices mentioned here:
>> >> http://lkml.kernel.org/r/CAErSpo56jB1Bf2JtYCGKXZBZqRF1jXFxGmeewPX_e6vSXueGyA@mail.gmail.com
>> >>
>> >> where the device can be configured as either an endpoint or a root port,
>> >> and the endpoint BARs are still visible when configured as a root port.
>> >>
>> >
>> > It is true that X-Gene PCIe port can be configured as EP, however the
>> > the FIXUP is required not because of the BARs are still visible when
>> > configured as EP in past. X-Gene PCIe port, when configured as RC,
>> > uses BAR0-BAR1 of RC's configuration space as inbound BARs. Entire DDR
>> > region is mapped in these BARs so that it is accessible for EP devices
>> > for DMA. So if the fixup is not done during enumeration, whole
>> > outbound memory resource space gets assigned to RC and nothing is left
>> > EP devices.
>>
>> I'm not familiar with the concept of an "inbound BAR"; at least I'm
>> not aware of anything like this in the PCI specs.  I think it might
>> reduce confusion if we avoided calling them "BARs".  They happen to be
>> at the same addresses where real BARs would be, but they certainly
>> don't behave like real BARs.
>
> So what does the lspci look like?
>

[root@...tang ~]# lspci -s 0000:00:00.0 -v
0000:00:00.0 PCI bridge: Applied Micro Circuits Corp. Device e004 (rev
04) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at <ignored> (64-bit, prefetchable)
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: 80800000-809fffff
Prefetchable memory behind bridge: 0000000080000000-00000000807fffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] Power Management version 3
Capabilities: [100] Advanced Error Reporting
Capabilities: [180] #19
Capabilities: [150] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
Kernel driver in use: pcieport

> If x-gene has an otherwise correct bridge config space and only the
> 0/1 BARs have a non-standard meaning, that I'd agree with Bjorn, hide
> all access to these registers from the kernel (and tell your HW crew
> to read the specs, because it is very clear what those registers are
> supposed to do) .
>

Ok.

> If x-gene doesn't even have a bridge config space, then there are much
> bigger problems, and these corrupt BARs are just the start.
>
> Jason
--
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/