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: <87czvokgdk.wl-maz@kernel.org>
Date:   Wed, 24 Mar 2021 10:14:47 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Nathan Chancellor <nathan@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        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 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.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.