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.
> > 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
