* 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. Dave > > > One question i have here, is that where exactly will the MH code > > exist in QEMU ? > > I assume it will be only x86 platform specific code, we probably will > never support it on other platforms ? > > So it will probably exist in hw/i386, something similar to "microvm" > support and using the same TYPE_X86_MACHINE ? > > I don't think it should be x86 only. The migration handler receiver > should be completely CPU agnostic. It's possible other CPUs will grow > an encrypted memory confidential computing capability (Power already > has one and ARM is "thinking" about it, but even if it doesn't, there's > a similar problem if you want to use trustzone isolation in VMs). I > would envisage migration working substantially similarly on all of them > (need to ask an agent in the guest to wrap an encrypted page for > transport) so I think we should add this capability to the generic QEMU > migration code and let other architectures take advantage of it as they > grow the facility. > > > Also if we are not going to use the existing KVM support code and > > adding some duplicate KVM interface code, do we need to interface > > with this added KVM code via the QEMU accelerator framework, or > > simply invoke this KVM code statically ? > > I think we need to design the interface as cleanly as possible, so it > just depends what's easiest. We certainly need some KVM support for > the mirror CPUs, I think but it's not clear to me yet what the simplest > way to do the interface is. > > James > > -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK
