Jesse,

I wanted to follow up here… I think this is a pretty exciting feature and I wanted to see what next steps are. Is this something that you’re planning to or can start contributing to the Kata project?

Thanks
Eric

From: "Larrew, Jesse" <Jesse.Larrew@amd.com>
Date: Friday, February 23, 2018 at 7:11 PM
To: Jon Olson <jonolson@google.com>
Cc: "Singh, Brijesh" <brijesh.singh@amd.com>, "Kaplan, David" <David.Kaplan@amd.com>, "Hollingsworth, Brent" <brent.hollingsworth@amd.com>, "kata-dev@lists.katacontainers.io" <kata-dev@lists.katacontainers.io>, "Woller, Thomas" <thomas.woller@amd.com>
Subject: Re: [kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)

From: Jon Olson [mailto:jonolson@google.com]
Sent: Friday, February 23, 2018 6:58 PM
To: Larrew, Jesse <Jesse.Larrew@amd.com>
Cc: Castelino, Manohar R <manohar.r.castelino@intel.com>; Samuel Ortiz <sameo@linux.intel.com>; Hollingsworth, Brent <brent.hollingsworth@amd.com>; kata-dev@lists.katacontainers.io; Singh, Brijesh <brijesh.singh@amd.com>; Kaplan, David <David.Kaplan@amd.com>; Woller, Thomas <thomas.woller@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@amd.com> wrote:

> From: Castelino, Manohar R [mailto:manohar.r.castelino@intel.com]
> Sent: Friday, February 23, 2018 3:53 PM
> To: Larrew, Jesse <Jesse.Larrew@amd.com>; Samuel Ortiz
> <sameo@linux.intel.com>
> Cc: Hollingsworth, Brent <brent.hollingsworth@amd.com>; Woller, Thomas
> <thomas.woller@amd.com>; Kaplan, David <David.Kaplan@amd.com>; kata-
> dev@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.