* Re: SVSM v1.00 and GHCB v2.03 specifications available
2023-10-06 14:26 ` Tom Lendacky
@ 2023-10-07 21:48 ` Dionna Amalie Glaze
0 siblings, 0 replies; 4+ messages in thread
From: Dionna Amalie Glaze @ 2023-10-07 21:48 UTC (permalink / raw)
To: Tom Lendacky; +Cc: Stefano Garzarella, linux-coco@lists.linux.dev
The services manifest table uses the terms "service GUID" and "service
data" when later in the vTPM section, the terms seem to change to
"service attestation GUID" and "manifest data". If these are indeed
the same things, please use consistent terminology. If they're
different, how are they different?
The fact that the data is specifically meant for attestation seems to
suggest that neither of the terms are appropriate, and that we should
use "service report" instead, to evoke more integrity expectations
from the interface.
What is the SVSM's notion of a "service"? Just something that produces
data in these service attestation calls (plus "core services")? I'm
not sure how to understand if there is an unstated but expected "1
GUID/entry per service" constraint here. There's nothing about the
"core services" having entries in the output, or explicitly not having
entries in the output.
The document's section "Core protocol services" seems to associate a
service with protocol # * call ID, but that seems inconsistent with
also calling each of these "calls". The fact that there are 32 bits
for protocol numbers, 32 bits for call ID, and 32 bits for protocol
version makes the 128 bits for these service GUIDs somewhat confusing
to assign a correspondence to.
My thoughts:
a. there may be multiple services provided through a single protocol,
but that protocol doesn't yet exist
b. GUIDs are used for the table because that's been a common data
format across the certificate data blob and how EDK2 represents data,
but there still is a 1<->1 correspondence between protocols and GUIDs?
c. manifest versions are redundant, and new versions can be associated
with different GUIDs. The fact that a version can be requested but is
not also required to be represented in the service/manifest data makes
me want to require the version at the top of the data or do away with
versions and just use different GUIDs when the ABI changes.
On the topic of "manifest version", the fact that there can be
multiple possible versions for each service makes SVSM_ATTEST_SERVICES
too awkward to continue being useful as formats evolve. The vTPM
protocol states that /only/ version 0 will be used in the
SVSM_ATTEST_SERVICES output.
It seems the SVSM_ATTEST_SERVICES operation /cannot/ get every
service's "manifest data" that a user wants unless any of the
following
a. there is an additional variable size input that allows a user to
name specific services and assign a requested manifest version,
b. the service can decide which version it will advertise when
enumerated and make the choice unambiguous by including the version in
the output.
c. manifest versions are removed and a service can enumerate its data
in all the "versions" it wants through different guid entries, though
this can also be a waste of time and memory
Those would help save the cost of round-trips with the SVSM and with
the AMD-SP, which seems to be the point of including all the integrity
information in the enumeration's output to begin with, as opposed to a
service inventory giving a list to individually query with
SVSM_ATTEST_SINGLE_SERVICE.
On Fri, Oct 6, 2023 at 7:26 AM Tom Lendacky <thomas.lendacky@amd.com> wrote:
>
> On 10/6/23 09:18, Stefano Garzarella wrote:
> > Hi Tom,
> >
> > On Wed, Oct 4, 2023 at 7:30 PM Tom Lendacky <thomas.lendacky@amd.com> wrote:
> >>
> >> The new versions of the subject specifications are now available. The
> >> https://www.amd.com/sev webpage will be updated shortly with the new
> >> links.
> >>
> >> In the mean time...
> >>
> >> The v1.00 SVSM specification is available here:
> >>
> >> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
> >
> > I think there's a little typo on page 30, section 7.2
> > SVSM_ATTEST_SINGLE_SERVICE Call.
> > RCX Description: "gPA of the attestation services operation structure, see
> > Table 11: Attest Services Operation"
> > ^
> > this should be "Table 13: Attest Single Service Operation", right?
>
> Yes, that should be Table 13. I'll work on getting that updated.
>
> Thanks,
> Tom
>
> >
> > Thanks,
> > Stefano
> >
> >>
> >> the v2.03 GHCB specification that adds support needed for running an
> >> SVSM is available here:
> >>
> >> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
> >>
> >> Thanks,
> >> Tom
> >>
> >
> >
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 4+ messages in thread