Message-ID: <285168ca-3b28-440e-91c7-a0c7707e29b9@amd.com>
Date: Tue, 6 Feb 2024 12:53:32 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: "Kuppuswamy, Sathyanarayanan" <sathyanarayanan.kuppuswamy@...el.com>,
 Dan Williams <dan.j.williams@...el.com>, linux-kernel@...r.kernel.org,
 x86@...nel.org
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 "H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Michael Roth <michael.roth@....com>,
 Ashish Kalra <ashish.kalra@....com>
Subject: Re: [PATCH 10/11] x86/sev: Extend the config-fs attestation support
 for an SVSM

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@....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@...ts.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@...ts.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@...ts.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@...ts.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@...ts.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

> 
>>

Powered by blists - more mailing lists