[libvirt] [PATCH 3/4] conf: introduce sev element in domain

Erik Skultety eskultet at redhat.com
Wed Feb 28 09:22:16 UTC 2018


[...]

> >
> > > +      </dd>
> > > +      <dt><code>policy</code></dt>
> > > +      <dd>The <code>policy</code> attribute provides the guest policy which must
> > > +      be maintained by the SEV firmware. This policy is enforced by the firmware
> > > +      and restricts what configuration and operational commands can be performed
> > > +      on this guest by the hypervisor. The guest policy provided during guest
> > > +      launch is bound to the guest and cannot be changed throughout the lifetime
> > > +      of the guest. The policy is also transmitted during snapshot and migration
> > > +      flows and enforced on the destination platform.
> >
> > So this is a hex number. Any documentation on the possible values?
>
>
> I can provide the link of the complete documentation and if needed then I
> can document here.
>
>
> >
> > > +      </dd>
> > > +      <dt><code>dh-cert</code></dt>
> > > +      <dd>The <code>dh-cert</code> attribute provides the guest owners public
> > > +      Diffie-Hellman (DH) key. The key is used to negotiate a master secret
> > > +      key between the SEV firmware and guest owner. This master secret key is
> > > +      then used to establish a trusted channel between SEV firmware and guest
> > > +      owner. The value must be encoded in base64.
> > > +      </dd>
> > > +      <dt><code>session</code></dt>
> > > +      <dd>The <code>session</code> attribute provides the guest owners session
> > > +      blob defined in SEV API spec. The value must be encoded in base64.
> >
> > This should also be more documented.
> >
>
> From x86 software point of view this is a blob of input which comes from the
> guest owner and must be passed as-is. The blob definition may change from
> one SEV firmware to another hence I don't see any reason for documenting
> this. I will provide link to SEV spec in case if someone want to find the
> details on blob and what exactly it contains etc etc.
>
>
>
> > > +      </dd>
> > > +    </dl>
> > > +
> > > +    <p>Note: More information about <code>policy</code> bit definition, <code>
> > > +    dh</code> and <code>session</code> is available in SEV API spec.</p>
> >
> > At least by providing the specification document. Preferably commiting
> > it to the libvirt repository so that it does not change URIs in the
> > future.
> >
>
> Will do, so far the link has been static and I am okay with putting it
> either in here or commit description or both.

"so far" doesn't mean the link isn't going to die with newer revisions of SEV
and we really don't want to have dangling URIs in our documentation. However, I
don't agree with Peter here that we should be committing the spec into the
repo, the spec contains lots of details, many of whic are not necessarily
relevant to libvirt, I'd therefore suggest to document all the possible values
for each element here explicitly, adding a precise tag of which revision of SEV
this is compatible with and which version of libvirt introduced the support for
it in order to make absolutely clear what libvirt consumers can expect from us
enabling this feature, should AMD introduce more values in future revisions of
SEV, since everyone can use google to get to the current revision for any
particular details and differences.

Erik




More information about the libvir-list mailing list