linux-kernel - Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB 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]

Date:   Thu, 21 Nov 2019 14:26:15 +0100
From:   Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
To:     Andrew Murray <andrew.murray@....com>
Cc:     Florian Fainelli <f.fainelli@...il.com>, mbrugger@...e.com,
        maz@...nel.org, phil@...pberrypi.org, linux-kernel@...r.kernel.org,
        jeremy.linton@....com, Eric Anholt <eric@...olt.net>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        bcm-kernel-feedback-list@...adcom.com,
        Stefan Wahren <wahrenst@....net>, james.quinlan@...adcom.com,
        linux-pci@...r.kernel.org, Bjorn Helgaas <bhelgaas@...gle.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-rpi-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host
 controller driver

On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote:
> On Wed, Nov 20, 2019 at 08:53:30PM +0100, Nicolas Saenz Julienne wrote:
> One purpose of this function is to validate that the information given in the
> device tree is valid - I've seen other feedback on these lists where the view
> is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
> to this view would be a justification for removing this validation -
> especially
> given that the bindings you include have only one dma-range (in any case if
> there are constraints you ought to include them in the binding document).
> 
> Though the problem with this point of view is that if the DT is wrong, it may
> be possible for the driver to work well enough to do some function but with
> some horrible side effects that are difficult to track down to a bad DT.

As for the validation, I think in this specific case it's still worthwhile. As
you might know, there is a bug on the first revision of RPI4's PCIe integration
which blocks any access higher than 3GB. Further revisions fix this and allow
full memory addressing.

I've been working with Phil Elwell (from the RPi foundation) to solve this in a
way that plays well with upstream and this driver (I'll be able to test the new
revision before this gets in). The solution is, unsurprisingly, for the
firmware to edit the DTB passed to the kernel based on the board revision.
Given that there is some live manipulation of the dma-ranges I'd rather leave
the validation check.

If you don't disagree with the above I'll add an extra code comment explaining
why we feel the need to verify the device-tree contents.

Regards,
Nicolas

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)