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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 6 Aug 2018 16:49:25 +0530
From:   Siddhesh Poyarekar <siddhesh@...plt.org>
To:     Mikulas Patocka <mpatocka@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     Florian Weimer <fweimer@...hat.com>,
        Andrew Pinski <pinskia@...il.com>,
        Richard Earnshaw <Richard.Earnshaw@....com>,
        Ramana Radhakrishnan <ramana.gcc@...glemail.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        GNU C Library <libc-alpha@...rceware.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Russell King <linux@...linux.org.uk>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Tulio Magno Quites Machado Filho <tuliom@...ux.ibm.com>
Subject: Re: framebuffer corruption due to overlapping stp instructions on
 arm64

On 08/06/2018 04:01 PM, Mikulas Patocka wrote:
> I think there are three possible solutions:
> 
> 1. provide an alternative memcpy implementation that doesn't do unaligned
> accesses and recompile the graphics software with -mstrict-align

Given that there's already a tunable glibc.cpu.cached_memopt for powerpc 
that (as Tulio clarified elsewhere) essentially does the same thing for 
cache-inhibited memory, it wouldn't be too much of an overhead to put in 
another ifunc implementation that gets chosen only when one sets this 
tunable.  In fact, we could reuse the C string routines for this to 
avoid adding yet another assembly implementation to have to support. 
That way we can minimally fix the issue at hand without regressing 
existing uses.

You can then set the glibc.cpu.cached_memopt tunable in the default 
environment for your board[1] or for applications that need it (e.g. 
whenever DISPLAY is exported or something like that).

The only difference from Power would be that cpu.noncached==0 for Power 
by default whereas for aarch64 it will be the other way around.  It 
shouldn't be too hard to enhance the framework to set platform-specific 
defaults.

Siddhesh

[1] Or if you're feeling particularly generous, help us implement 
systemwide tunables since you have an actual use case for it :)