lkml.org 
[lkml]   [2024]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 10/11] x86/sev: Extend the config-fs attestation support for an SVSM
From
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

>
>>

\
 
 \ /
  Last update: 2024-05-27 14:51    [W:0.257 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site