Messages in this thread |  | | Subject | Re: [PATCH v2 3/4] drm/ttm, drm/vmwgfx: Correctly support support AMD memory encryption | From | Thomas Hellström (VMware) <> | Date | Wed, 4 Sep 2019 00:15:26 +0200 |
| |
On 9/4/19 12:08 AM, Thomas Hellström (VMware) wrote: > On 9/3/19 11:46 PM, Andy Lutomirski wrote: >> On Tue, Sep 3, 2019 at 2:05 PM Thomas Hellström (VMware) >> <thomas_os@shipmail.org> wrote: >>> On 9/3/19 10:51 PM, Dave Hansen wrote: >>>> On 9/3/19 1:36 PM, Thomas Hellström (VMware) wrote: >>>>> So the question here should really be, can we determine already at >>>>> mmap >>>>> time whether backing memory will be unencrypted and adjust the *real* >>>>> vma->vm_page_prot under the mmap_sem? >>>>> >>>>> Possibly, but that requires populating the buffer with memory at mmap >>>>> time rather than at first fault time. >>>> I'm not connecting the dots. >>>> >>>> vma->vm_page_prot is used to create a VMA's PTEs regardless of if they >>>> are created at mmap() or fault time. If we establish a good >>>> vma->vm_page_prot, can't we just use it forever for demand faults? >>> With SEV I think that we could possibly establish the encryption flags >>> at vma creation time. But thinking of it, it would actually break with >>> SME where buffer content can be moved between encrypted system memory >>> and unencrypted graphics card PCI memory behind user-space's back. That >>> would imply killing all user-space encrypted PTEs and at fault time set >>> up new ones pointing to unencrypted PCI memory.. >>> >>>> Or, are you concerned that if an attempt is made to demand-fault page >>>> that's incompatible with vma->vm_page_prot that we have to SEGV? >>>> >>>>> And it still requires knowledge whether the device DMA is always >>>>> unencrypted (or if SEV is active). >>>> I may be getting mixed up on MKTME (the Intel memory encryption) and >>>> SEV. Is SEV supported on all memory types? Page cache, hugetlbfs, >>>> anonymous? Or just anonymous? >>> SEV AFAIK encrypts *all* memory except DMA memory. To do that it uses a >>> SWIOTLB backed by unencrypted memory, and it also flips coherent DMA >>> memory to unencrypted (which is a very slow operation and patch 4 deals >>> with caching such memory). >>> >> I'm still lost. You have some fancy VMA where the backing pages >> change behind the application's back. This isn't particularly novel >> -- plain old anonymous memory and plain old mapped files do this too. >> Can't you all the insert_pfn APIs and call it a day? What's so >> special that you need all this magic? ISTM you should be able to >> allocate memory that's addressable by the device (dma_alloc_coherent() >> or whatever) and then map it into user memory just like you'd map any >> other page. >> >> I feel like I'm missing something here. > > Yes, so in this case we use dma_alloc_coherent(). > > With SEV, that gives us unencrypted pages. (Pages whose linear kernel > map is marked unencrypted). With SME that (typcially) gives us > encrypted pages. In both these cases, vm_get_page_prot() returns > an encrypted page protection, which lands in vma->vm_page_prot. > > In the SEV case, we therefore need to modify the page protection to > unencrypted. Hence we need to know whether we're running under SEV and > therefore need to modify the protection. If not, the user-space PTE > would incorrectly have the encryption flag set. > > /Thomas > > And, of course, had we not been "fancy", we could have used dma_mmap_coherent(), which in theory should set up the correct user-space page protection. But now we're moving stuff around so we can't.
/Thomas
|  |