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

[Daniel P. Berrange]

On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
> > So I could see a flow like the following:
> 
> 
> The flow looks good
> 
> > 
> > 
> >    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
> > 
> 
> 
> One thing which is not clear to me is, how do we know that we are asked
> to launch SEV guest? Are you thinking that <sev> tag in the XML will
> hint libvirt that GO has asked to launch a SEV guest?

Yes, the existance of the <sev> tag is the indicator that informs
libvirt that SEV *must* be used for the guest.

> >    3. Libvirt generates the QEMU cli arg to enable SEV using
> >       the XML data and starts QEMU, leaving CPUs paused
> > 
> 
> 
> I am looking at [1] to get the feel for how do we model it in the XML.
> As you can see I am using ad-hoc <qemu:args> to create the sev-guest
> object. Currently, sev-guest object accepts the following properties:
> 
> dh-cert-file: <file containing the GO DH key>
> session-info-file: <file contain the GO session info>
> policy: <int32 GO policy>
> 
> I believe the new XML model will influence the property input type,
> Any recommendation on how do model this part ? thank you so much.

That looks ok to me - even if QEMU wants the data provided in
files on disk, libvirt can just create the files on the fly
from the data it has in the <sev> element in the XML file.
Since they're only needed during startup, libvirt can then
easily delete the files the moment QEMU has completed its
startup.

> 
> [1] https://libvirt.org/formatdomain.html#elementsCPU
> 
> 
> >    4. QEMU emits a SEV_MEASURE event containing the measurement
> >       blob
> > 
> >    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()
> > 
> >       providing the optional secret, then
> > 
> >           virDomainResume()
> > 
> >       to let QEMU continue
> > 
> > 
> > 
> > 
> > Regards,
> > Daniel
> > 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|