[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/13] Add support for Mirror VM.
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [RFC PATCH 00/13] Add support for Mirror VM. |
Date: |
Wed, 18 Aug 2021 16:31:13 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
* James Bottomley (jejb@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.
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@redhat.com / Manchester, UK
- Re: [RFC PATCH 00/13] Add support for Mirror VM., (continued)
Re: [RFC PATCH 00/13] Add support for Mirror VM., Ashish Kalra, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Paolo Bonzini, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Ashish Kalra, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Paolo Bonzini, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Dr. David Alan Gilbert, 2021/08/16
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Ashish Kalra, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., James Bottomley, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM.,
Dr. David Alan Gilbert <=
- Re: [RFC PATCH 00/13] Add support for Mirror VM., James Bottomley, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Dr. David Alan Gilbert, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., James Bottomley, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., Dr. David Alan Gilbert, 2021/08/18
- Re: [RFC PATCH 00/13] Add support for Mirror VM., James Bottomley, 2021/08/18
Re: [RFC PATCH 00/13] Add support for Mirror VM., Paolo Bonzini, 2021/08/18
Re: [RFC PATCH 00/13] Add support for Mirror VM., Dr. David Alan Gilbert, 2021/08/16
Re: [RFC PATCH 00/13] Add support for Mirror VM., Steve Rutherford, 2021/08/16