On Wed, 2021-08-18 at 16:31 +0100, Dr. David Alan Gilbert wrote: > * James Bottomley (j...@linux.ibm.com) wrote: > > On Wed, 2021-08-18 at 10:31 +0000, Ashish Kalra wrote: > > > Hello Paolo, > > > > > > On Mon, Aug 16, 2021 at 05:38:55PM +0200, Paolo Bonzini wrote: > > > > On 16/08/21 17:13, Ashish Kalra wrote: > > > > > > > I think that once the mirror VM starts booting and > > > > > > > running the UEFI code, it might be only during the PEI or > > > > > > > DXE phase where it will start actually running the MH > > > > > > > code, so mirror VM probably still need to handles > > > > > > > KVM_EXIT_IO when SEC phase does I/O, I can see PIC > > > > > > > accesses and Debug Agent initialization stuff in SEC > > > > > > > startup code. > > > > > > That may be a design of the migration helper code that you > > > > > > were working with, but it's not necessary. > > > > > > > > > > > Actually my comments are about a more generic MH code. > > > > > > > > I don't think that would be a good idea; designing QEMU's > > > > migration helper interface to be as constrained as possible is > > > > a good thing. The migration helper is extremely security > > > > sensitive code, so it should not expose itself to the attack > > > > surface of the whole of QEMU. > > > > The attack surface of the MH in the guest is simply the API. The > > API needs to do two things: > > > > 1. validate a correct endpoint and negotiate a wrapping key > > 2. When requested by QEMU, wrap a section of guest encrypted > > memory > > with the wrapping key and return it. > > > > The big security risk is in 1. if the MH can be tricked into > > communicating with the wrong endpoint it will leak the entire > > guest. If we can lock that down, I don't see any particular > > security problem with 2. So, provided we get the security > > properties of the API correct, I think we won't have to worry over > > much about exposure of the API. > > Well, we'd have to make sure it only does stuff on behalf of qemu; if > the guest can ever write to MH's memory it could do something that > the guest shouldn't be able to.
Given the lack of SMI, we can't guarantee that with plain SEV and -ES. Once we move to -SNP, we can use VMPLs to achieve this. But realistically, given the above API, even if the guest is malicious, what can it do? I think it's simply return bogus pages that cause a crash on start after migration, which doesn't look like a huge risk to the cloud to me (it's more a self destructive act on behalf of the guest). James
