Re: Interactive launch over QMP socket?

[Connor Kuehl <ckuehl@redhat.com>]

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.

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