Re: [RFC PATCH 00/13] Add support for Mirror VM. - Tobin Feldman-Fitzthum

From: Tobin Feldman-Fitzthum <tobin@linux.ibm.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Steve Rutherford <srutherford@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ashish Kalra <Ashish.Kalra@amd.com>,
	thomas.lendacky@amd.com, brijesh.singh@amd.com,
	ehabkost@redhat.com, kvm@vger.kernel.org, mst@redhat.com,
	tobin@ibm.com, jejb@linux.ibm.com, richard.henderson@linaro.org,
	qemu-devel@nongnu.org, frankeh@us.ibm.com,
	dovmurik@linux.vnet.ibm.com
Subject: Re: [RFC PATCH 00/13] Add support for Mirror VM.
Date: Wed, 18 Aug 2021 17:42:16 -0400	[thread overview]
Message-ID: <c1d8dbca-c6a9-58da-6f95-b33b74e0485a@linux.ibm.com> (raw)
In-Reply-To: <YR1ZvArdq4sKVyTJ@work-vm>

On 8/18/21 3:04 PM, Dr. David Alan Gilbert wrote:
> * Tobin Feldman-Fitzthum (tobin@linux.ibm.com) wrote:
>> On 8/17/21 6:04 PM, Steve Rutherford wrote:
>>> Ahh, It sounds like you are looking into sidestepping the existing
>>> AMD-SP flows for migration. I assume the idea is to spin up a VM on
>>> the target side, and have the two VMs attest to each other. How do the
>>> two sides know if the other is legitimate? I take it that the source
>>> is directing the LAUNCH flows?
>> Yeah we don't use PSP migration flows at all. We don't need to send the MH
>> code from the source to the target because the MH lives in firmware, which
>> is common between the two.
> Are you relying on the target firmware to be *identical* or purely for
> it to be *compatible* ?  It's normal for a migration to be the result of
> wanting to do an upgrade; and that means the destination build of OVMF
> might be newer (or older, or ...).
>
> Dave

This is a good point. The migration handler on the source and target 
must have the same memory footprint or bad things will happen. Using the 
same firmware on the source and target is an easy way to guarantee this. 
Since the MH in OVMF is not a contiguous region of memory, but a group 
of functions scattered around OVMF, it is a bit difficult to guarantee 
that the memory footprint is the same if the build is different.

-Tobin

>
>
>> We start the target like a normal VM rather than
>> waiting for an incoming migration. The plan is to treat the target like a
>> normal VM for attestation as well. The guest owner will attest the target VM
>> just like they would any other VM that is started on their behalf. Secret
>> injection can be used to establish a shared key for the source and target.
>>
>> -Tobin
>>
>>> --Steve
>>>