linux-kernel - Re: [PATCH v2 0/4] Have TTM support SEV encryption with coherent memory

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] [day] [month] [year] [list]

Message-ID: <5a41afa1-a1f9-128c-222a-542f102024b9@shipmail.org>
Date:   Thu, 5 Sep 2019 12:43:42 +0200
From:   Thomas Hellström (VMware) 
        <thomas_os@...pmail.org>
To:     dri-devel@...ts.freedesktop.org, pv-drivers@...are.com,
        linux-graphics-maintainer@...are.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/4] Have TTM support SEV encryption with coherent
 memory

On 9/3/19 3:15 PM, Thomas Hellström (VMware) wrote:
> With SEV memory encryption and in some cases also with SME memory
> encryption, coherent memory is unencrypted. In those cases, TTM doesn't
> set up the correct page protection. Fix this by having the TTM
> coherent page allocator call into the platform code to determine whether
> coherent memory is encrypted or not, and modify the page protection if
> it is not.
>
> v2:
> - Use force_dma_unencrypted() rather than sev_active() to catch also the
>    special SME encryption cases.

So, this patchset is obviously withdrawn since

a) We shouldn't have TTM shortcut the dma API in this way.
b) To reviewers it was pretty unclear why this was needed in the first 
place, and became
even more unclear in the context of the TTM fault handler.

I've just send out an RFC patchset that basically does the same but in 
the context of dma_mmap_coherent() I hope this clears things up and we 
should hopefully be able to use a new
dma API function from within the TTM fault handler.

Thanks,

Thomas