Open Stack

> From: Tao Peng [mailto:bergwolf at hyper.sh]
> Sent: Friday, February 23, 2018 7:56 AM
> To: Larrew, Jesse <Jesse.Larrew at amd.com>
> Cc: kata-dev at lists.katacontainers.io; Hollingsworth, Brent
> <brent.hollingsworth 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 12:32 AM, Larrew, Jesse <Jesse.Larrew at amd.com>
> wrote:
> > Ah! Yes, live migration of encrypted guests is supported by the hardware.
> Qemu support is still being actively developed though. The details of
> migrating encrypted VMs are discussed in our Secure Encrypted Virtualization
> API [1]. Basically, the AMD Secure Processor re-encrypts and integrity-
> protects the guest memory into discrete "packets" that can be sent to the
> destination machine. The transport/integrity keys used for migration are
> ephemeral keys negotiated with the receiving machine using a Diffie-
> Hellman exchange.
> >
> > Live migration is useful for VMs that need to be stateful. However, my
> impression of container use cases is that they are encouraged to be
> stateless. For stateless containers, it would most likely be quicker to simply
> throw away the container and start a new one on the destination machine.
> Do you have specific use cases that require the ability to migrate containers?
> >
> Yes. We have an optimization [1] based on the qemu live migration
> feature which let us share the initial part of guest memory among
> guests on the same host. It's a quite useful feature for vm-based
> container workload because the kernel and initramfs are most likely
> the same for all guests on the host.
> 
> [1]:
> https://github.com/hyperhq/qemu/commit/162b05b38ddb8505c209cf3c570
> d70c76427c8a5
> 

Ah, I understand now. That’s a neat idea!

SEV forces all code pages to be encrypted, so this technique wouldn’t work without modification. Since the guest kernel knows where all of its pages are and has access to a network stack, the kernel could theoretically establish a connection to a dummy guest and migrate/clone *itself* into the dummy.

> Cheers,
> Tao
> 

Sincerely,
Jesse