> On Sep 3, 2019, at 3:15 PM, Thomas Hellström (VMware) > <thomas...@shipmail.org> wrote: > >> 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...@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. >>
I’m still confused. You got unencrypted pages with an unencrypted PFN. Why do you need to fiddle? You have a PFN, and you’re inserting it with vmf_insert_pfn(). This should just work, no? There doesn’t seem to be any real funny business in dma_mmap_attrs() or dma_common_mmap(). But, reading this, I have more questions: Can’t you get rid of cvma by using vmf_insert_pfn_prot()? Would it make sense to add a vmf_insert_dma_page() to directly do exactly what you’re trying to do? And a broader question just because I’m still confused: why isn’t the encryption bit in the PFN? The whole SEV/SME system seems like it’s trying a bit to hard to be fully invisible to the kernel. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
