Open Stack

From: Jon Olson [mailto:jonolson at google.com]
Sent: Friday, February 23, 2018 6:58 PM
To: Larrew, Jesse <Jesse.Larrew at amd.com>
Cc: Castelino, Manohar R <manohar.r.castelino at intel.com>; Samuel Ortiz <sameo at linux.intel.com>; Hollingsworth, Brent <brent.hollingsworth at amd.com>; kata-dev at lists.katacontainers.io; Singh, Brijesh <brijesh.singh at amd.com>; Kaplan, David <David.Kaplan at amd.com>; Woller, Thomas <thomas.woller at amd.com>
Subject: Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)


On Fri, Feb 23, 2018 at 4:42 PM Larrew, Jesse <Jesse.Larrew at amd.com<mailto:Jesse.Larrew at amd.com>> wrote:
> From: Castelino, Manohar R [mailto:manohar.r.castelino at intel.com<mailto:manohar.r.castelino at intel.com>]
> Sent: Friday, February 23, 2018 3:53 PM
> To: Larrew, Jesse <Jesse.Larrew at amd.com<mailto:Jesse.Larrew at amd.com>>; Samuel Ortiz
> <sameo at linux.intel.com<mailto:sameo at linux.intel.com>>
> Cc: Hollingsworth, Brent <brent.hollingsworth at amd.com<mailto:brent.hollingsworth at amd.com>>; Woller, Thomas
> <thomas.woller at amd.com<mailto:thomas.woller at amd.com>>; Kaplan, David <David.Kaplan at amd.com<mailto:David.Kaplan at amd.com>>; kata-
> dev at lists.katacontainers.io<mailto:dev at lists.katacontainers.io>
> Subject: RE: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)
>
> Jesse,
>
> > On EPYC, our IOMMU doesn't yet support SEV, so DMA to/from devices
> needs
> > to be done using unencrypted pages. It was easy to implement this using
> the
> > bounce buffers provided by SWIOTLB. As you guessed, a quick change to
> > vring_use_dma_api() got virtio support working properly:
>
> Clear Containers today supports direct device assignment via SRIOV.
> This requires pre-allocation and pinning of VM memory.
> Will this continue to work?
>
> Also we have been working on reverse ballooning. i.e. free unused memory
> from the VM back to the host. Is there is a way to get this to work with
> encrypted memory
>
> For more details about the patches
> https://gist.github.com/sboeuf/fc71f0218a81997251ee0d7668df2bd9
>
> -manohar
>
>

Hi Manohar,

SEV also requires the guest memory to be pre-allocated and pinned [1], so that's not a problem. As long as the PF drivers in the guest are using the dma apis, everything should continue to work.

That's surprising -- I can see where reclaim would be challenging without something like a balloon, but why must the be initially backed? What happens if you leave a page unbacked and attempt to lazily back it on an EPT fault?

[JDL] You’re right Jon. I misspoke above. The memory only needs to be pinned; the backing pages can be faulted in on demand. Sorry for the confusion.


Similarly, the reverse ballooning patches should also work with SEV. In fact, I would argue that SEV compliments this feature by ensuring that physical page contents aren't exposed to the host when the guest uses MADV_FREE. I've CC'ed our KVM expert, Brijesh Singh, just in case he sees something that I missed.

Sincerely,
Jesse

[1] In order to ensure that memory blocks with identical data will encrypt to different ciphertext, SEV mixes the physical address into the encryption algorithm. As a result, if a page of memory is moved to a different physical address, it will not decrypt properly. This also defeats block-move attacks on the guest memory, but it also requires all guest memory to be pinned.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180224/b46437c0/attachment-0001.html>