Re: Interactive launch over QMP socket?

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Connor Kuehl (ckuehl@redhat.com) wrote:
> On 2/10/21 1:06 PM, James Bottomley wrote:
> > On Wed, 2021-02-10 at 12:46 -0600, Connor Kuehl wrote:
> > > Right, I didn't mean to include cbitpos in consideration for this.
> > > I'm only interested in supplying the session, policy, and certificate
> > > info over the socket.
> > > 
> > > Shouldn't the session, policy, and certificate information only be
> > > required in time for the KVM_SEV_LAUNCH_START ioctl call? This is
> > > the place I'm interested in waiting for the relevant data.
> > 
> > Well, it could, but I see the session information as being the same as
> > the image file, which is also a command line argument, so if you can do
> > the image file on the command line, why not the session info as well?
> 
> It would be interesting to allow remote delivery of the initial image as
> well because for purposes of attestation I would argue that the guest owner
> should have as much of the locus of control as possible. However, because
> the guest image is unlikely to change between launches/guests, it's probably
> more helpful to deliver it to the host, let it cache it, and supply that via
> a command line argument. I'm mainly interested in the session blob, policy,
> and certificate for now though.
> 
> I don't see a similar value in caching a session blob or policy because it
> is trivial to generate these and put them in a JSON object and send them on
> demand. I think that chopping up part of the attestation process, setting it
> aside, and having to figure out how to deliver it to the host where the QEMU
> process will launch creates an impedance mismatch. Usability impedance
> mismatches tend to motivate the creation of one or more
> automation/translation layers to automate that "glue" away.
> 
> Extending QMP to allow end-to-end attestation via QEMU removes the need for
> that glue and improves interoperability with other client implementations
> who care about attestation. Providers would just need to point out the QMP
> endpoint for guest owners. It lends itself to a more "atomic"
> transaction-like attestation experience overall.

Note that QMP is not 'safe' - anyone who has control of QMP can cause
the qemu to try and open arbitrary files on the host (by binding them as
disks for example) or allocate memory (by hot adding RAM); so raw QMP is
not something that you could give to a guest owner.

Dave

> > The other problem is the session info is exchanged for a launch handle
> > in kvm_init, which is machine_init in qemu terms.  That's called
> > phenomenally early, so there's not much of kvm to pause before you do
> > that.  So either qemu has to be rewritten to pause before processing
> > command line arguments, and then any argument can be added over QMP, or
> > the handle exchange has to occur later.
> 
> Ah, I see, thank you.
> 
> Connor
> 
> > James
> > 
> > 
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK