Re: [Qemu-devel] [libvirt] libvirt/QEMU/SEV interaction

[Erik Skultety]

[...]

> >
> >     > c) what existing communicate interface can be used between libvirt 
> > and qemu
> >     > to get the measurement ? can we add a new qemu monitor command
> >     > 'get_sev_measurement' to get the measurement ? (step 10)
> >
> >     Yes, QMP commands seeem most likely.
> >
> >     > d) how to pass the secret blob from libvirt to qemu ? should we 
> > consider
> >     > adding a new object (sev-guest-secret) -- libvirt can add the object 
> > through
> >     > qemu monitor.
> >
> >     Yeah, that looks like a viable option too.
>
> So I could see a flow like the following:
>
>
>   1. mgmt tool calls  virConnectGetCapabilities. This returns an XML
>      document that includes the following
>
>       <host>
>          ...other bits...
>         <sev>
>         <platform-key>...hex encoded PDH key...</platform-key>
>       </sev>
>       </host>
>
>   2. mgmt tool requests to start a guest calling virCreateXML(),
>      passing VIR_DOMAIN_START_PAUSED. The XML would include
>
>       <sev>
>         <owner-key>...hex encode DH key...</owner-key>
>       <session-info>..hex encode info...</session-info>
>       <policy>...int32 value..</policy>
>       </sev>
>
>
>      if <sev> is provided and VIR_DOMAIN_START_PAUSED is missing,
>      libvirt would report an error and refuse to start the guest
>
>   3. Libvirt generates the QEMU cli arg to enable SEV using
>      the XML data and starts QEMU, leaving CPUs paused
>
>   4. QEMU emits a SEV_MEASURE event containing the measurement
>      blob

Speaking of which, I expect QEMU to have a QMP command to retrieve the
measurement, in which case I think libvirt has to provide an API for the user
to retrieve the measurement in case libvirtd crashes somewhere between setting
up QEMU and waiting for the measurement event from QEMU, or simply because the
GO missed the event for some unspecified reason.

>
>   5. Libvirt catches the QEMU event and emits its own
>      VIR_CONNECT_DOMAIN_EVENT_SEV_MEASURE event containing
>      the measurement blob
>
>   6. GO does its validation of the measurement
>
>   7a  If validation failed, then virDomainDestroy() to stop QEMU
>
>   7b  If validation succeeed
>
>      Optionally call
>
>          virDomainSetSEVSecret()

Given the fact that we're likely introducing a new <sev> element to the XML
config, I'm more inclined to utilizing the existing virSecret interfaces (as
was originally suggested) instead of creating a vendor-specific API. You could
have an optional secret sub-element within the <sev> element and libvirt would
simply check if that secret has a value set, once the GO issues
virDomainResume(). Any particular reason for having a specific API for this that
I'm missing?

Other than that I like the initial proposal for the design.

Erik