* James Bottomley (jejb@xxxxxxxxxxxxx) wrote: > On Thu, 2021-08-19 at 15:28 +0100, Dr. David Alan Gilbert wrote: > > * James Bottomley (jejb@xxxxxxxxxxxxx) wrote: > > > On Thu, 2021-08-19 at 09:22 +0100, Dr. David Alan Gilbert wrote: > [...] > > > > I think it really does have to cope with migration to a new > > > > version of host. > > > > > > Well, you're thinking of OVMF as belonging to the host because of > > > the way it is supplied, but think about the way it works in > > > practice now, forgetting about confidential computing: OVMF is RAM > > > resident in ordinary guests, so when you migrate them, the whole of > > > OVMF (or at least what's left at runtime) goes with the migration, > > > thus it's not possible to change the guest OVMF by migration. The > > > above is really just an extension of that principle, the only > > > difference for confidential computing being you have to have an > > > image of the current OVMF ROM in the target to seed migration. > > > > > > Technically, the problem is we can't overwrite running code and > > > once the guest is re-sited to the target, the OVMF there has to > > > match exactly what was on the source for the RT to still > > > function. Once the migration has run, the OVMF on the target must > > > be identical to what was on the source (including internally > > > allocated OVMF memory), and if we can't copy the MH code, we have > > > to rely on the target image providing this identical code and we > > > copy the rest. > > > > I'm OK with the OVMF now being part of the guest image, and having to > > exist on both; it's a bit delicate though unless we have a way to > > check it (is there an attest of the destination happening here?) > > There will be in the final version. The attestations of the source and > target, being the hash of the OVMF (with the registers in the -ES > case), should be the same (modulo any firmware updates to the PSP, > whose firmware version is also hashed) to guarantee the OVMF is the > same on both sides. We'll definitely take an action to get QEMU to > verify this ... made a lot easier now we have signed attestations ... Hmm; I'm not sure you're allowed to have QEMU verify that - we don't trust it; you need to have either the firmware say it's OK to migrate to the destination (using the existing PSP mechanism) or get the source MH to verify a quote from the destination. [Somewhere along the line, if you're not using the PSP, I think you also need to check the guest policy to check it is allowed to migrate]. Dave > James > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
