* James Bottomley (jejb@xxxxxxxxxxxxx) wrote: > On Wed, 2021-08-18 at 16:31 +0100, Dr. David Alan Gilbert wrote: > > * James Bottomley (jejb@xxxxxxxxxxxxx) 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. Doesn't the MH have access to different slots and running on separate vCPUs; so it's still got some separation? > 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). I'm a bit worried about the data structures that are shared between the migration code in qemu and the MH; the code in qemu is going to have to be paranoid about not trusting anything coming from the MH. Dave > James > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
