* Tobin Feldman-Fitzthum (tobin@xxxxxxxxxxxxx) wrote: > On 8/17/21 6:04 PM, Steve Rutherford wrote: > > On Tue, Aug 17, 2021 at 1:50 PM Tobin Feldman-Fitzthum > > <tobin@xxxxxxxxxxxxx> wrote: > > > This is essentially what we do in our prototype, although we have an > > > even simpler approach. We have a 1:1 mapping that maps an address to > > > itself with the cbit set. During Migration QEMU asks the migration > > > handler to import/export encrypted pages and provides the GPA for said > > > page. Since the migration handler only exports/imports encrypted pages, > > > we can have the cbit set for every page in our mapping. We can still use > > > OVMF functions with these mappings because they are on encrypted pages. > > > The MH does need to use a few shared pages (to communicate with QEMU, > > > for instance), so we have another mapping without the cbit that is at a > > > large offset. > > > > > > I think this is basically equivalent to what you suggest. As you point > > > out above, this approach does require that any page that will be > > > exported/imported by the MH is mapped in the guest. Is this a bad > > > assumption? The VMSA for SEV-ES is one example of a region that is > > > encrypted but not mapped in the guest (the PSP handles it directly). We > > > have been planning to map the VMSA into the guest to support migration > > > with SEV-ES (along with other changes). > > 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 > 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 > > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
