linux-kernel - Re: cleanup the dma

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:   Fri, 23 Aug 2019 21:58:04 +0000
From:   Paul Burton <paul.burton@...s.com>
To:     Christoph Hellwig <hch@....de>
CC:     "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        Guan Xuetao <gxt@....edu.cn>,
        Shawn Anastasio <shawn@...stas.io>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Robin Murphy <robin.murphy@....com>,
        James Hogan <jhogan@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: cleanup the dma_pgprot handling

Hi Christoph,

On Fri, Aug 16, 2019 at 09:07:48AM +0200, Christoph Hellwig wrote:
> I'd still like to hear a confirmation from the mips folks how
> the write combibe attribute can or can't work with the KSEG1
> uncached segment.

Quoting section 4.8 "Cacheability and Coherency Attributes and Access
Types" of "MIPS Architecture Volume 1: Introduction to the MIPS32
Architecture" (MD00080, revision 6.01):

https://www.mips.com/?do-download=introduction-to-the-mips32-architecture-v6-01

> Memory access types are specified by architecturally-defined and
> implementation-specific Cacheability and Coherency Attribute bits
> (CCAs) generated by the MMU for the access.
>
> Slightly different cacheability and coherency attributes such as
> “cached coherent, update on write” and “cached coherent, exclusive on
> write” can map to the same memory access type; in this case they both
> map to cached coherent. In order to map to the same access type, the
> fundamental mechanisms of both CCAs must be the same.
>
> When the operation of the instruction is affected, the instructions
> are described in terms of memory access types. The load and store
> operations in a processor proceed according to the specific CCA of the
> reference, however, and the pseudocode for load and store common
> functions uses the CCA value rather than the corresponding memory
> access type.

So I believe uncached & uncached accelerated are another case like that
described above - they're 2 different CCAs but the same "access type",
namely uncached.

Section 4.9 then goes on to forbid mixing access types, but not CCAs.

It would be nice if the precise mapping from CCA to access type was
provided, but I don't see that anywhere. I can check with the
architecture team to be sure, but to my knowledge we're fine to mix
access via kseg1 (ie. uncached) & mappings with CCA=7 (uncached
accelerated).

Thanks,
    Paul