Messages in this thread | | | Date | Tue, 6 Feb 2024 12:53:32 -0600 | Subject | Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM | From | Tom Lendacky <> |
| |
On 2/5/24 17:29, Kuppuswamy, Sathyanarayanan wrote: > > On 2/1/24 11:10 PM, Dan Williams wrote: >> Tom Lendacky 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. >>> >>> - '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. >>> >>> - 'manifestblob' (output) >>> Used to return the service manifest associated with the attestation >>> report. >>> >>> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> >>> --- >>> Documentation/ABI/testing/configfs-tsm | 55 ++++++++++ >>> arch/x86/include/asm/sev.h | 31 +++++- >>> arch/x86/kernel/sev.c | 50 +++++++++ >>> drivers/virt/coco/sev-guest/sev-guest.c | 137 ++++++++++++++++++++++++ >>> drivers/virt/coco/tsm.c | 95 +++++++++++++++- >>> include/linux/tsm.h | 11 ++ >>> 6 files changed, 376 insertions(+), 3 deletions(-) >>> >>> diff --git a/Documentation/ABI/testing/configfs-tsm b/Documentation/ABI/testing/configfs-tsm >>> index dd24202b5ba5..c5423987d323 100644 >>> --- a/Documentation/ABI/testing/configfs-tsm >>> +++ b/Documentation/ABI/testing/configfs-tsm >>> @@ -31,6 +31,21 @@ Description: >>> Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ. >>> https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf >>> >>> +What: /sys/kernel/config/tsm/report/$name/manifestblob >>> +Date: January, 2024 >>> +KernelVersion: v6.9 >>> +Contact: linux-coco@lists.linux.dev >>> +Description: >>> + (RO) Optional supplemental data that a TSM may emit, visibility >>> + of this attribute depends on TSM, and may be empty if no >>> + manifest data is available. >>> + >>> + When @provider is "sev_guest" and the "svsm" attribute is set >>> + this file contains the service manifest used for the SVSM >>> + attestation report from Secure VM Service Module for SEV-SNP >>> + Guests v1.00 Section 7. >>> + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf >> I wish configfs had better dynamic visibility so that this could be >> hidden when not active... oh well. >> >>> + >>> What: /sys/kernel/config/tsm/report/$name/provider >>> Date: September, 2023 >>> KernelVersion: v6.7 >>> @@ -80,3 +95,43 @@ Contact: linux-coco@lists.linux.dev >>> Description: >>> (RO) Indicates the minimum permissible value that can be written >>> to @privlevel. >>> + >>> +What: /sys/kernel/config/tsm/report/$name/svsm >>> +Date: January, 2024 >>> +KernelVersion: v6.9 >>> +Contact: linux-coco@lists.linux.dev >>> +Description: >>> + (WO) Attribute is visible if a TSM implementation provider >>> + supports the concept of attestation reports for TVMs running >>> + under an SVSM, like SEV-SNP. Specifying any non-zero value >> Just use kstrtobool just to have a bit more form to it, and who knows >> maybe keeping some non-zero numbers reserved turns out useful someday. >> >> ...or see below, maybe this shouldn't be an "svsm" flag. >> >>> + implies that the attestation report should come from the SVSM. >>> + Secure VM Service Module for SEV-SNP Guests v1.00 Section 7. >>> + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf >> So this affects the output format of outblob? I think @outblob should >> probably document the fact that it depends on @provider, @privlevel, and >> now @svsm. Probably all of the format links should live under @outblob >> not @provider. >> >> I worry that "svsm" is not going to be the last name for a selected >> family of services that might convey something to outblob. I wonder if >> this should just be a generic "service" attribute where "svsm" is only >> supported value to write today. Another service family could be >> introduced later and reuse the service_guid concept, or kernel gets >> lucky and a de-facto standard heads off proliferation here. >> >>> + >>> +What: /sys/kernel/config/tsm/report/$name/service_guid >>> +Date: January, 2024 >>> +KernelVersion: v6.9 >>> +Contact: linux-coco@lists.linux.dev >>> +Description: >>> + (WO) Attribute is visible if a TSM implementation provider >>> + supports the concept of attestation reports for TVMs running >>> + under an SVSM, like SEV-SNP. Specifying a empty or null GUID >>> + (00000000-0000-0000-0000-000000) requests all active services >>> + within the SVSM be part of the attestation report. Specifying >>> + a non-null GUID requests an attestation report of just the >>> + specified service using the manifest form specified by the >>> + service_version attribute. >>> + Secure VM Service Module for SEV-SNP Guests v1.00 Section 7. >>> + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf >> Given the small number of service GUIDs so far perhaps save someone the >> URL fetch and list it here? > > How will user know about the available GUIDs? Is there a way for user to > query this list?
In a sense, yes. You can request an all services attestation which will return a manifest containing all the active services GUIDs.
> >> >>> + >>> +What: /sys/kernel/config/tsm/report/$name/service_version >>> +Date: January, 2024 >>> +KernelVersion: v6.9 >>> +Contact: linux-coco@lists.linux.dev >>> +Description: >>> + (WO) Attribute is visible if a TSM implementation provider >>> + supports the concept of attestation reports for TVMs running >>> + under an SVSM, like SEV-SNP. Indicates the service manifest >>> + version requested for the attestation report. >>> + Secure VM Service Module for SEV-SNP Guests v1.00 Section 7. >>> + https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf >> Perhaps document that version 1 is assumed and is always compatible? >> >> What prompts new versions and how does that discovered by guest software? > > Why user care about it? If it is going to affect manifestblob output, I > recommend adding that info there.
Will do.
Thanks, Tom
> >>
| |