[kata-dev] Kata with AMD Secure Encrypted Virtualization (SEV)

Ernst, Eric eric.ernst at intel.com
Fri Apr 6 19:08:08 UTC 2018


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?


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

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.


[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/20180406/c675e20d/attachment-0001.html>

More information about the kata-dev mailing list