linux-kernel - Re: [PATCH] irqchip/gic-v3: fix OF_BAD

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: <CAK8P3a2kVagwETi0_t0C=eGJ6UU=AXegL94UykfQdh7H292XYQ@mail.gmail.com>
Date:   Wed, 24 Mar 2021 11:55:04 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nathan Chancellor <nathan@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH] irqchip/gic-v3: fix OF_BAD_ADDR error handling

On Wed, Mar 24, 2021 at 11:14 AM Marc Zyngier <maz@...nel.org> wrote:
>
> On Tue, 23 Mar 2021 22:06:22 +0000,
> Nick Desaulniers <ndesaulniers@...gle.com> wrote:
> >
> > On Tue, Mar 23, 2021 at 6:18 AM Arnd Bergmann <arnd@...nel.org> wrote:
> > >
> > > From: Arnd Bergmann <arnd@...db.de>
> > >
> > > When building with extra warnings enabled, clang points out a
> > > mistake in the error handling:
> > >
> > > drivers/irqchip/irq-gic-v3-mbi.c:306:21: error: result of comparison of constant 18446744073709551615 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
> >
> > Looks like based on CONFIG_PHYS_ADDR_T_64BIT, phys_addr_t can be u64
> > or u32, but of_translate_address always returns a u64.  This is fine
> > for the current value of OF_BAD_ADDR, but I think there's a risk of
> > losing the top 32b of the return value of of_translate_address() here?
>
> If the DT describes a 64bit physical address, and that the (32bit)
> kernel isn't built to grok these addresses, then I'd say that the
> kernel cannot run on this HW, and that we don't need to worry much
> about this case.
>
> In general, CONFIG_PHYS_ADDR_T_64BIT must be selected by the arch code
> if anything above 32bit can be described in the PA space.

Right, this generally works fine, the OF_BAD_ADDR is just a little
hard to get right. Fortunately there are very few comparisons to
OF_BAD_ADDR in other drivers, so I don't think we have to do
anything about it. I looked through every other user of this and found
no problems there, either they use 64-bit temporaries, or they correctly
cast the results.

         Arnd