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: <m35yyzttil.fsf@t19.piap.pl>
Date:   Mon, 31 May 2021 06:30:10 +0200
From:   Krzysztof Hałasa <khalasa@...p.pl>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
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()

"Russell King (Oracle)" <linux@...linux.org.uk> writes:

>> 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.

For userspace, it's quite a corner case, basically development-only -
and I guess there are very few people who will do things like this.

The same problem can manifest itself without any kernel involvement -
it's enough to mmap /dev/mem and use LDM on in completely in userspace.
This can't be fixed - unless we disallow IPU mmap.

Perhaps making sure the bug is clearly documented is better than doing
a partial fix. Ideally NXP should document it in their papers, and we
should add notes to IPU driver code.

The last one - I guess I can do.
-- 
Krzysztof Hałasa

Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa