linux-kernel - Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in common code

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: <20180319160343.GA29002@lst.de>
Date:   Mon, 19 Mar 2018 17:03:43 +0100
From:   Christoph Hellwig <hch@....de>
To:     Will Deacon <will.deacon@....com>
Cc:     Robin Murphy <robin.murphy@....com>,
        Christoph Hellwig <hch@....de>, x86@...nel.org,
        Tom Lendacky <thomas.lendacky@....com>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        linux-kernel@...r.kernel.org, Muli Ben-Yehuda <mulix@...ix.org>,
        iommu@...ts.linux-foundation.org,
        David Woodhouse <dwmw2@...radead.org>,
        Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH 12/14] dma-direct: handle the memory encryption bit in
        common code

On Mon, Mar 19, 2018 at 03:48:33PM +0000, Will Deacon wrote:
> Why can't we just resolve the conflict by adding the underscores?

We can solve the conflict easily that way.  But that's not the point.

The point is that I've been fighting hard to consolidate dma code
given that the behavior really is common and not arch specific.  And
this one is another case like that:  the fact that the non-coherent
dma boundary is bigger than the exposed size is something that can
easily happen elsewhere, so there is no need to duplicate a lot
of code for that.

Nevermind that the commit should at least be three different patches:

 (1) revert the broken original commit
 (2) increase the dma min alignment
 (3) put the swiotlb workaround in place