linux-kernel - Re: [RFC PATCH] arm: i.MX6 Cortex-A9: Fix memory ordering inconsistency by disabling prefetch instructions

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:   Tue, 19 Jul 2022 16:33:15 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     James Morse <james.morse@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Russell King <linux@...linux.org.uk>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Michael Jeanson <mjeanson@...icios.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH] arm: i.MX6 Cortex-A9: Fix memory ordering
 inconsistency by disabling prefetch instructions

On Mon, Jul 18, 2022 at 4:51 PM Mathieu Desnoyers
<mathieu.desnoyers@...icios.com> wrote:

> Request for Feedback
> ====================
>
> This fix targets all i.MX configurations, but it is likely too broad (or
> too narrow). It would be great if people with access to different
> Freescale i.MX test boards, and test boards from other vendors, could try
> to reproduce the issue to figure out what would be the right scope for
> this fix.
>
> It would also be great if people with knowledge of the ARM CPU internals
> could help understanding whether this fix really fixes an issue between
> prefetch and memory barriers, or just happens to hide the issue. It
> would be good to understand whether this issue only affects PLDW or if
> it also affects the PLD instruction.

I don't have any relevant hardware at hand, but looked at this for a few
hours today, unfortunately without any notable success. Just documenting
what I did here:

- looked at the errata lists for cortex-a9 r2, for pl310 and for
imxq6q to see if
  anything stuck out. I assume you've already done the same, but I can confirm
  that the errata that would match the symptom are listed as fixed in r2p10
  or earlier.

- looked at objdump output from
  linux-image-5.18.0-0.bpo.1-armmp_5.18.2-1~bpo11+1_armhf.deb
  (not the same version, but hopefully be close enough), and compared that
  to v5.18.2 built with the same config using gcc-7.5 and gcc-10.3 to
  see if I could tell what is different. The output looks very similar, though
  my own gcc-10 apparently fails to inline arch_futex_atomic_op_inuser()
  and futex_atomic_op_inuser(). This looks like something we may want
  to force-inline in principle, but it seems unrelated to the bug you found
  since the debian vmlinux has these functions inlined and I don't think
  they are actually part of the broken code path.

- looked for other quad-core Cortex-A9 SoCs to find someone with a
  similar revision to check if they have the same bug. The closest I
  can  think of is the OMAP4 that uses an A9 r1p2.

- Looked at the disabled errata handling in arch/arm/Kconfig.
  Unfortunately a couple of the workarounds we have there are
  now always disabled because of a dependency on
  ARCH_MULTIPLATFORM. It's a long shot, but you could try
  removing the dependencies and enabling all the Cortex-A9
  fixes like ARM_ERRATA_742230, ARM_ERRATA_742231,
  ARM_ERRATA_743622, ARM_ERRATA_751472, and
  ARM_ERRATA_754327.

        Arnd