Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM

[Tom Lendacky]

On 1/29/24 14:04, Dionna Amalie Glaze wrote:
> On Mon, Jan 29, 2024 at 7:02 AM Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
> > On 1/26/24 19:27, Dionna Amalie Glaze wrote:
> > > On Fri, Jan 26, 2024 at 2:19 PM Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
> > > > When an SVSM is present, the guest can also request attestation reports
> > > > from the SVSM. These SVSM attestation reports can be used to attest the
> > > > SVSM and any services running within the SVSM.
> > > >
> > > > Extend the config-fs attestation support to allow for an SVSM attestation
> > > > report. This involves creating four (4) new config-fs attributes:
> > > >
> > > >     - 'svsm' (input)
> > > >       This attribute is used to determine whether the attestation request
> > > >       should be sent to the SVSM or to the SEV firmware.
> > >
> > > This is where I'm torn. If there's an SVSM, it's there to provide
> > > paravirtualization for unenlightened guests /or/ it's there to protect
> >
> > An SVSM is for enlightened guests. A para-visor would be for unenlightened
> > guests.
> >
> > > runtime measurement registers. I don't see there being any particular
> > > value in bifurcating the attestation report space by adding this
> > > option. If there's an SVSM present, the configfs-tsm report should
> > > return the full SVSM attestation only.
> >
> > I don't necessarily agree with that. The guest should still be able to
> > request a traditional attestation report.
> >
> > Maybe I can remove the SVSM attribute and direct the call based on
> > requested VMPL level. If VMPL0 is requested, it goes through the SVSM.
> > If VMPL1+ is requested, it goes to the ASP.
> >
> > That would mean that the privlevel_floor would need to stay at zero.
> >
> > > >     - 'service_guid' (input)
> > > >       Used for requesting the attestation of a single service within the
> > > >       SVSM. A null GUID implies that the SVSM_ATTEST_SERVICES call should
> > > >       be used to request the attestation report. A non-null GUID implies
> > > >       that the SVSM_ATTEST_SINGLE_SERVICE call should be used.
> > > >
> > > >     - 'service_version' (input)
> > > >       Used with the SVSM_ATTEST_SINGLE_SERVICE call, the service version
> > > >       represents a specific service manifest version be used for the
> > > >       attestation report.
> > >
> > > I know that this is specified for the SVSM, but I still don't know
> > > what the intended use case is such that we wouldn't simply always
> > > return the full service manifest.
> > > I can see an argument for an evidence requester not being ready for a
> > > new manifest version and wanting the older version until they can
> > > bridge the gap. I don't see that as needing configuration from the
> > > user space. We can either require new service GUIDs for new versions,
> > > require manifest ABIs to be internally versioned to be additive-only
> > > to not break verifiers that understand up to manifest byte X, or we
> > > allow breaking version changes through control plane configuration
> > > that's passed directly to the SVSM.
> > >
> > > New versions get new GUIDs allows for gradual deprecation at the
> > > expense of size. I think that is a reasonable trade-off to keep from
> > > making tsm/report vendor-specific.
> >
> > This was requested and discussed during the SVSM spec review and there
> > were no objections raised. See the this thread where this was discussed:
> >
> > https://lore.kernel.org/linux-coco/09819cb3-1938-fe86-b948-28aaffbe584e@xxxxxxx/
>
> We also hadn't had the configfs-tsm unification point, so I think it's
> worth folding in that discussion.
> In terms of querying specific services, would you help me with a
> concrete example of where the evidence collector ought to query a
> specific version instead of the service enumeration?

Here is where the request was initially brought up:

https://lore.kernel.org/linux-coco/fbc84da05c5343c5228c5adb697d4b66f1ea6308.camel@xxxxxxxxxxxxxxxxxxxxx/

> > The changes you're requesting would require a new version of the spec
> > and updates to the protocol.
>
> I think the changes I'm requesting are to just limit the exposure of
> the protocol to linux. What specifically about what I wrote requires a
> change to the spec? Is it the lack of plural handling of 'its GUID
> value' in "Each service will document its GUID value and the format of
> its manifest content."?

The spec is currently written so that a service has a single GUID. If I
understand correctly, you are asking that each version of the manifest
for a service gets a unique GUID. That would require a change to the
specification to document such a behavior and possibly a protocol
modification to somehow indicate to ignore the version field when
requesting a single service attestation or a new protocol that does not
take/use a version.

Thanks,
Tom

> > > >     - 'manifestblob' (output)
> > > >       Used to return the service manifest associated with the attestation
> > > >       report.
> > >
> > > Given the above, I think we can just append the manifest to the report
> > > since the report size is known a priori.
> >
> > We could have theoretically done the same thing with the auxblob (certs
> > data), but that is separate. I prefer the idea of having an individual
> > entry per piece of data being returned.
>
> Fair enough, another RO blob seems okay enough.
>
> > Thanks,
> > Tom
> >
> > >