linux-kernel - Re: [PATCH v8 3/4] clocksource/drivers: Add a goldfish-timer clocksource

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:   Sun, 16 Jan 2022 11:44:28 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Laurent Vivier <laurent@...ier.eu>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        John Stultz <john.stultz@...aro.org>,
        linux-rtc@...r.kernel.org, Jiaxun Yang <jiaxun.yang@...goat.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>
Subject: Re: [PATCH v8 3/4] clocksource/drivers: Add a goldfish-timer clocksource

On Sat, Jan 15, 2022 at 8:32 PM Laurent Vivier <laurent@...ier.eu> wrote:

> +
> +/* goldfish endianness depends on CPU endianness */
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +#define goldfish_ioread32 ioread32be
> +#define goldfish_iowrite32 iowrite32be
> +#else
> +#define goldfish_ioread32 ioread32
> +#define goldfish_iowrite32 iowrite32
> +#endif

This is not what I meant here, as you are breaking big-endian support
for all other
architectures in the process.

On architectures that support both big-endian and little-endian kernels, devices
(including emulated ones) can't know which type of kernel you are running, so
this has to be fixed by architecture. Ideally this macro should be in
an architecture
specific header file, but you can also just make this a check for m68k and  hope
that qemu doesn't duplicate this bug on architectures that gain support for this
driver in the future.

         Arnd