linux-kernel - Re: framebuffer corruption due to overlapping stp instructions on arm64

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LRH.2.02.1808060325110.3756@file01.intranet.prod.int.rdu2.redhat.com>
Date:   Mon, 6 Aug 2018 04:02:03 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@...hat.com>
To:     Florian Weimer <fweimer@...hat.com>
cc:     Andrew Pinski <pinskia@...il.com>,
        Richard Earnshaw <Richard.Earnshaw@....com>,
        ard.biesheuvel@...aro.org,
        Ramana Radhakrishnan <ramana.gcc@...glemail.com>,
        thomas.petazzoni@...e-electrons.com,
        GNU C Library <libc-alpha@...rceware.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>, linux@...linux.org.uk,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: framebuffer corruption due to overlapping stp instructions on
 arm64

On Sun, 5 Aug 2018, Florian Weimer wrote:

> On 08/04/2018 01:04 PM, Mikulas Patocka wrote:
> > There's plenty of memcpy's in the graphics stack. No one will be rewriting
> > all the graphics drivers because of tiny market share that ARM has in
> > desktop computers. So if you refuse to fix things and blame everyone else,
> > you can as well announce that you don't want to have PCIe graphics on ARM
> > at all.
> 
> The POWER toolchain maintainers said pretty much the same thing not too 
> long ago. I wonder how many architectures need to fail until the 
> graphics stack is finally fixed.
> 
> Thanks,
> Florian

If you say that your architecture doesn't support unaligned accesses at 
all, there's no problem - the compiler won't generate them and the libc 
won't contain them.

But if you say that your architecture supports unaligned accesses except 
for the framebuffer, then you have a problem - the compiler can't know 
which pointers point to the framebuffer and libc can't know either - you 
caused this problem by your architectural decision.

You can use 'volatile' to suppress memory optimizations, but it's 
impossible to go through the whole Linux graphics stack and add volatile 
to every pointer that may point to videoram. Even if you succeesed, new 
videoram accesses without volatile will appear after a year of 
development.

See for example the macros READ_ONCE and WRITE_ONCE in Linux kernel - they 
should be used when there's concurrent access to the particular variable, 
but mainstream architectures don't require them, so many kernel developers 
are omitting them in their code.

If you are building a supercomputer with a particular GPU, you can force 
the GPU vendor to provide POWER-compliant drivers. If you are building a 
workstation where the user can plug any GPU, forcing developers will go 
nowhere. You have to emulate the unaligned accesses and make sure that the 
next versions of your architecture support them in hardware.

Mikulas