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] [day] [month] [year] [list]

Message-ID: <CAL_Jsq+cVWTAa8GwfrDhmNHoVauT61oYnpMNpY1N0Bz-bMutHg@mail.gmail.com>
Date:   Mon, 9 Mar 2020 11:13:16 -0500
From:   Rob Herring <robh@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Lubomir Rintel <lkundrak@...sk>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jason Cooper <jason@...edaemon.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] irqchip/mmp: A pair of robustness fixed

On Sun, Mar 8, 2020 at 9:04 AM Marc Zyngier <maz@...nel.org> 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.

We don't really have a way to say a binding can only occur once or N
times in a DT. We'd have to have an SoC schema that listed out all the
nodes in the DT and forbid any additional nodes. I don't think that's
too useful as if there's only 1 instance for a given schema, then the
schema is not too useful as the schema has a equal chance of being
wrong.

Is there something inherent about the h/w that prevents more than one
instance? If support of more than one instance is a kernel limitation
(because no current SoC needs more than 1), then shouldn't the kernel
protect against this?

Rob