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]
Date:   Sun, 16 Jan 2022 17:19:43 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Laurent Vivier <laurent@...ier.eu>
Cc:     Arnd Bergmann <arnd@...db.de>,
        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>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>
Subject: Re: [PATCH v8 3/4] clocksource/drivers: Add a goldfish-timer clocksource

On Sun, Jan 16, 2022 at 12:54 PM Laurent Vivier <laurent@...ier.eu> wrote:
>
> Virtio has exactly the same problem in the past (prio to v1.0), and it uses __LITTLE_ENDIAN in
> virtio_legacy_is_little_endian() to know the endianness of the device.

Right, that was my point, let's not duplicate the bug from pre-standard virtio.

> So the code can become:
>
> #ifdef __LITTLE_ENDIAN
> #define goldfish_ioread32 ioread32
> #define goldfish_iowrite32 iowrite32
> #else
> #define goldfish_ioread32 ioread32be
> #define goldfish_iowrite32 iowrite32be
> #endif

This is exactly the same as what you had before, it continues to break when
host and guest disagree on the endianess.

> What do you prefer: CONFIG_M68K or __LITTLE_ENDIAN?

Checking for CONFIG_M68K at least has a chance of working, provided
that all existing qemu implementations agree on the semantics here.

       Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ