Open Stack

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

-- 
bergwolf at hyper.sh