Open Stack

On Fri, Feb 23, 2018 at 4:42 PM Larrew, Jesse <Jesse.Larrew at amd.com> wrote:

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


>
> 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.
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20180224/2c03adc9/attachment.html>