[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interactive launch over QMP socket?

From: Connor Kuehl
Subject: Re: Interactive launch over QMP socket?
Date: Wed, 10 Feb 2021 14:39:38 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]