linux-kernel - Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed

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: <861rq27o6s.wl-maz@kernel.org>
Date:   Sun, 08 Mar 2020 17:26:35 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Lubomir Rintel <lkundrak@...sk>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        linux-kernel@...r.kernel.org, Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed

On Sun, 08 Mar 2020 14:46:04 +0000,
Lubomir Rintel <lkundrak@...sk> wrote:
> 
> On Sun, Mar 08, 2020 at 02:04:34PM +0000, Marc Zyngier wrote:
> > On Wed, 19 Feb 2020 09:00:22 +0100
> > Lubomir Rintel <lkundrak@...sk> wrote:
> > 
> > [+RobH]
> > 
> > Lubomir,
> > 
> > > Hi,
> > > 
> > > please consider applying these two patches. Thery are not strictly
> > > necessary, but improve diagnostics in case the DT is faulty.
> > 
> > Can't we instead make sure our DT infrastructure checks for these? I'm
> > very reluctant to add more "DT validation" to the kernel, as it feels
> > like the wrong place to do this.
> 
> These are not really problems of the DT infrastructure.

They are. The DT bindings describes the constraints (or at least
should), and the DT infrastructure could, at least in theory, check
them at compile time. Adding the checks to the kernel defeats the
single benefit of DT, which is independence from the kernel.

> It's that the driver has some constrains resulting from use of
> global data ([PATCH 1]) and statically sized arrays ([PATCH 2])
> without enforcing them.
> 
> It's probably easier to mess up DT than to mess up board files,

No, both models can be just as easily broken if people write them
without thinking twice.

> but regardless of that, being a little defensive and checking the
> bounds of arrays is probably a good programming practice anyways.

Is there even any example of such broken DT in the tree?

	M.

-- 
Jazz is not dead, it just smells funny.