[Top][All Lists]

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

Re: Interactive launch over QMP socket?

From: James Bottomley
Subject: Re: Interactive launch over QMP socket?
Date: Wed, 10 Feb 2021 11:06:49 -0800
User-agent: Evolution 3.34.4

On Wed, 2021-02-10 at 12:46 -0600, Connor Kuehl wrote:
> On 2/10/21 12:14 PM, James Bottomley wrote:
> > > I would like to add a message type to QMP which allows guest
> > > owners to supply this data over a socket and _not_ require these
> > > components a priori via command line arguments. In doing so, this
> > > would allow for a 100% remote attestation process over the
> > > socket. However, I'm not sure how to express this interactive
> > > "waiting" for this data to become available with internal APIs
> > > (assuming it's not supplied as a command  line argument).
> > 
> > Well, I never understood why qemu can't deduce the value of cbitpos
> > ... it even errors out if you get it wrong.  However, other things
> > like the policy and the session file have to be present at start of
> > day. They're not things that can be passed in after qemu starts
> > building the machine image because they need to be present to begin
> > building it.
> 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?

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.


reply via email to

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