Messages in this thread | | | Date | Wed, 21 Oct 2020 13:03:22 -0300 | From | Jason Gunthorpe <> | Subject | Re: AMD SME encrpytion and PCI BAR pages to user space |
| |
On Wed, Oct 21, 2020 at 10:30:23AM -0500, Tom Lendacky wrote: > On 10/21/20 6:59 AM, Jason Gunthorpe wrote: > > On Mon, Oct 19, 2020 at 11:36:16AM -0500, Tom Lendacky wrote: > > > >>> io_remap_pfn_range()? Is there use cases where a caller actually wants > >>> encrypted io memory? > >> > >> As long as you never have physical memory / ram being mapped in this path, > >> it seems that applying pgprot_decrypted() would be ok. > > > > I made a patch along these lines: > > > > https://github.com/jgunthorpe/linux/commit/fc990842983f3530b72fcceafed84bd6075174a1 > > > > Just waiting for the 0-day bots to check it > > > > I now have a report that SME works OK but when the same test is done > > inside a VM with SEV it fails again - is there something else needed > > for the SEV case? > > Probably. I would assume that it is getting past the MMIO issue, since the > above patch should cover SEV, too. But, with SEV, all DMA to and from the > guest is unencrypted. I'm not familiar with how the DMA is setup and > performed in this situation, but if the DMA is occurring to userspace > buffers that are mapped as encrypted, then the resulting access will be > ciphertext (either reading unencrypted data from the device as encrypted > or writing encrypted data to the device that should be unencrypted). There > isn't currently an API to allow userspace to change its mapping from > encrypted to unencrypted.
Oh, interesting.. Yes the issue is no userspace DMA stuff uses the DMA API correctly (because it is in userspace)
So SWIOTLB tricks don't work, I wish the dma_map could fail for these situations
I would have guessed it used some vIOMMU and setup decrpytion just like the host does..
Thanks, Jason
| |