Re: [edk2-devel] RFC: Fast Migration for SEV and SEV-ES - blueprint and proof of concept

[James Bottomley <jejb@linux.ibm.com>]

On Mon, 2020-11-09 at 17:37 -0500, Tobin Feldman-Fitzthum wrote:
> On 2020-11-09 14:56, Dr. David Alan Gilbert wrote:
> > * Tobin Feldman-Fitzthum (tobin@linux.ibm.com) wrote:
[...]
> > > We're still working out some of the details in QEMU, but the
> > > basic idea of transferring memory is that each time the HV needs
> > > to send a page to the target, it will ask the Migration Handler
> > > in the guest for a version of the page that is encrypted with a
> > > transport key.  Since the MH is inside the guest, it can read
> > > from any address in guest memory. The Migration Handlers on the
> > > source and the target will share a key. Once the source encrypts
> > > the requested page with the transport key, it can safely hand it
> > > off to the HV. Once the page reaches the target, the target HV
> > > will pass the page into the Migration Handler, which will decrypt
> > > using the transport key and move the page to the appropriate
> > > address.
> > 
> > So somehow we have to get that transport key negotiated and into
> > the the migration-handlers.
> 
> Inject-launch-secret is one of the main pieces here. James might have
> more info about this step.

So there are a couple of ways I was thinking this could work.  In the
current slow migration, the PSPs on each end validate each other by
exchanging keys.  We could do something similar by having the two MHs
do an ECDHE exchange to agree a trusted transfer key between them and
then having them both exchange trusted information about the SEV
environment i.e. both validating each other.

However, the alternative and simpler way is simply to have the machine
owner control everything.  So encrypted boot would provision two
secrets: one for the actual encrypted root which grub needs but the
other would be what the MH needs.  The MH secret would be the private
part of an ECDH key (effectively the MH identity) and the public ECDH
key of the MH source, so only the source MH would be able to make
encrypted contact for migration.  On boot from image, the public key
part would be empty indicating boot should proceed normally.  On
migration, we make sure we know the source public key and provision it
to the target along with a random target key.  To trigger the
migration, we have to tell the source what the target's public key is
and they can now make encrypted contact in a manner that should be
cryptographically secure.  The MH ECDH key would exist for the lifetime
of the VM on a SEV system and would be destroyed on either image
shutdown or successful migration. 

James