linux-kernel - Re: [PATCH v12 2/5] tty: goldfish: introduce gf_ioread32()/gf

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: <CAK8P3a32PRo4OJmUPmgnhp_14biz4bfs5BnDXej1itwOfkuvKA@mail.gmail.com>
Date:   Wed, 26 Jan 2022 15:15:23 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Greg KH <greg@...ah.com>
Cc:     Laurent Vivier <laurent@...ier.eu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-rtc@...r.kernel.org, Alessandro Zummo <a.zummo@...ertech.it>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        John Stultz <john.stultz@...aro.org>,
        "# 3.4.x" <stable@...r.kernel.org>
Subject: Re: [PATCH v12 2/5] tty: goldfish: introduce gf_ioread32()/gf_iowrite32()

On Wed, Jan 26, 2022 at 2:41 PM Greg KH <greg@...ah.com> wrote:
>
> On Fri, Jan 21, 2022 at 09:07:35PM +0100, Laurent Vivier wrote:
> > Revert
> > commit da31de35cd2f ("tty: goldfish: use __raw_writel()/__raw_readl()")
>
> Why?
>
> > and define gf_ioread32()/gf_iowrite32() to be able to use accessors
> > defined by the architecture.
>
> What does this do?

The reverted commit was an incorrect workaround for an old qemu bug:

The goldfish devices are apparently defined as "native" endianness,
which in qemu is whatever the architecture maintainers thought it should
be at the time (little-endian on arm, big-endian on powerpc, board
specific on mips, etc.) but independent of what kernel is actually running
on the machine if the CPU supports both.

m68k in qemu picked big-endian here, which is the opposite of what
the kernel driver does, presumably because that is the endianness of
the CPU itself.

Since we can't fix qemu any more, and runtime detection doesn't work
on machines without devicetree, having a sane default (whatever the
driver used to do) and an architecture specific override for those that
got it wrong is probably our best option.

       Arnd