Open Stack

> -----Original Message-----
> 
> On Thu, Feb 22, 2018 at 6:06 AM, Larrew, Jesse <Jesse.Larrew at amd.com>
> wrote:
> > Hi all,
> >
> > The virtualization instructions in the latest AMD EPYC server processors
> have been enhanced with a memory encryption feature that could provide
> projects like Kata Containers with unique security capabilities compared to
> their non-virtualized counterparts. We call this feature Secure Encrypted
> Virtualization (or SEV) and would be interested in collaborating with the Kata
> Container community to enable support for containers with encrypted
> memory.
> >
> > In short, we've added an inline AES engine to our memory controller that
> encrypts data written to system DRAM and decrypts data read from DRAM.
> The encryption keys are generated from a TRNG in the onboard AMD Secure
> Processor (SP) and programmed into the memory controller as needed in a
> manner that is never visible to software. Additionally, our virtualization
> instructions have been enhanced to be able to associate a VM ASID with a
> unique encryption key, so each VM (or container) can keep the contents of
> its memory confidential from the host and/or other tenant VMs/containers.
> The guest kernel can choose which pages to encrypt and which to share with
> the host by setting a bit in the guest page tables, which puts the guest in
> complete control of the visibility of their data in the cloud. More information
> can be found in our Memory Encryption whitepaper [1] and in the
> Architecture Programmer's Manual [2].
> >
> > Linux kernel support for SEV has been merged into the 4.15 and upcoming
> 4.16 kernels. OVMF BIOS support has been merged as well. The qemu
> changes are still being upstreamed, but the patches are available for testing
> on github [3].
> >
> > With the above support in place, we have developed a proof-of-concept
> demo that is based on Clear Containers. Since the Clear Containers project
> had already done the heavy lifting to run container workloads inside of a VM,
> it was rather straightforward to add support to encrypt those VMs using SEV.
> The required changes are summarized below:
> >         * Container kernel:
> >                 - Add SEV support patches from the Linux kernel repo in [3].
> >                 - Force virtio to use the DMA API (and hence SWIOTLB) when
> adding/removing buffers to/from the virtio ring buffer.
> >                 - SEV requires a memory copy in order to perform the encryption,
> so zero-copy solutions using DAX for the container initial user space will not
> work.
> >                         + Build in a small initramfs to use as the guest kernel initial user
> space.
> >                         + Include the updated container agent binary and supporting
> libs (~14MB total).
> >         * Container agent:
> >                 - Update the agent not to use the pivot_root() method from the
> initramfs environment, and perform the pivot to the container workload
> filesystem manually instead.
> >         * Container runtime:
> >                 - Add the new qemu command line options for starting an SEV
> guest.
> >         * Qemu-lite:
> >                 - Add the SEV support patches from the qemu repo in [3].
> >
> Hi Jesse,
> 
> Thanks for the proposal! SEV matches greatly with the Kata Container
> threat model and can be quite useful in a cloud environment.
> 
> I have one question though -- how does it handle qemu vm clone?
> 
> Cheers,
> Tao
> 

Hi Tao,

I’m not familiar with qemu VM clone. Is there any documentation or source files I could browse to learn more?

Sincerely,
Jesse