linux-kernel - Re: Data corruption on i.MX6 IPU in arm_copy_from

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: <20210528143544.GQ30436@shell.armlinux.org.uk>
Date:   Fri, 28 May 2021 15:35:44 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Krzysztof Hałasa <khalasa@...p.pl>
Cc:     linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: Data corruption on i.MX6 IPU in arm_copy_from_user()

On Fri, May 28, 2021 at 12:02:52PM +0200, Krzysztof Hałasa wrote:
> "Russell King (Oracle)" <linux@...linux.org.uk> writes:
> 
> > In any case, looking at the architecture reference manual, LDM is
> > permitted on device and strongly ordered mappings, and the memory
> > subsystem is required to decompose it into a series of 32-bit accesses.
> > So, it sounds to me like there could be a hardware bug in the buses/IPU
> > causing this.
> 
> It seems so.
> 
> I modified the kernel IPU module a bit, initialized a bunch of IPU
> registers to known values (1..0xD). Results (from 1 to 13 IPU
> registers) obtained with different instructions:
> 
> readl(13 consecutive registers): CSI = 1 2 3 4 5 6 7 8 9 A B C D
> 1 = register #0 and so on - readl() results are obviously correct.
> 
> LDM1:  1 (not corrupted)
> LDM2:  1 3
> LDM3:  1 3 4
> LDM4:  2 3 4 4
> LDM5:  1 3 4 5 6
> LDM6:  1 3 4 5 6 7
> LDM7:  1 3 4 5 6 7 8
> LDM8:  2 3 4 5 6 7 8 8
> LDM9:  1 3 4 5 6 7 8 9 A
> LDM10: 1 3 4 5 6 7 8 9 A B
> LDM11: 1 3 4 5 6 7 8 9 A B C
> LDM12: 1 3 4 5 6 7 8 9 A B C D

That's rather sad, and does look very much like a hardware bug.

The question is what to do about it... there's Linus' "do not break
userspace" edict and that's exactly what this change has done. So I
suppose we're going to have to revert the change and put up with
everything being slightly slower on arm32 than it otherwise would
have been. That probably means we'll end up with almost every kernel
tree out there carrying a revert of the revert to work around the
fact that seemingly NXP broke their hardware - which itself is not
a good idea. I guess we're just going to have to put up with that.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!