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