linux-kernel - Re: [PATCH 11/13] 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: <20180313131005.GA6260@lst.de>
Date:   Tue, 13 Mar 2018 14:10:05 +0100
From:   Christoph Hellwig <hch@....de>
To:     Tom Lendacky <thomas.lendacky@....com>
Cc:     Christoph Hellwig <hch@....de>, x86@...nel.org,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        David Woodhouse <dwmw2@...radead.org>,
        Muli Ben-Yehuda <mulix@...ix.org>,
        Jon Mason <jdmason@...zu.us>, Joerg Roedel <joro@...tes.org>,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/13] dma-direct: handle the memory encryption bit in
        common code

On Mon, Mar 12, 2018 at 02:48:51PM -0500, Tom Lendacky wrote:
> Ok, I found one issue that allows this to work when the IOMMU isn't
> enabled (see below).

Thanks, folded!

> But the bigger issue is when the IOMMU is enabled.  The IOMMU code uses
> a common mapping routine to create the I/O page tables.  This routine
> assumes that all memory being mapped is encrypted and therefore sets the
> encryption bit in the I/O page tables.  With this patch, the call to
> dma_alloc_direct() now returns un-encrypted memory which results in an
> encryption mis-match.  I think keeping dma_alloc_direct() as it was prior
> to this patch is the way to go.  It allows SME DMA allocations to remain
> encrypted and avoids added complexity in the amd_iommu.c file.  This
> would mean that SEV would still have special DMA operations (so that the
> alloc/free can change the memory to un-encrypted).
> 
> What do you think?

In terms of logic you are right.  I still don't like keeping a just
slightly tweaked version of dma_alloc_direct around just for this, it
will be perpetually out of sync in terms of features and bug fixes.

What do you think about this version that does the decision at runtime:

	http://git.infradead.org/users/hch/misc.git/commitdiff/b89f24dc856595dc7610d672bf077195ab0dabf4

The full tree is available here for testing:

	git://git.infradead.org/users/hch/misc.git dma-direct-x86