RE: [EXTERNAL] Re: SVSM Attestation and vTPM specification additions - v0.60

[Jon Lange <jlange@microsoft.com>]

One of the design goals of SVSM was to maximize the compatibility between all guest OSes and all SVSM implementations.  The idea that there are SVSM-specific protocols seems, in general, to be directly contradictory to this goal.  Why would it be desirable for a guest to have a conversation with its SVSM that is specific to the architecture of that SVSM?  I would think it far superior to define every sort of interaction as a generic contract that could be supported by every SVSM implementation to maximize compatibility in accordance with the stated goal.

Put another way, seeing any upstream implementation that provides functionality that is complete with SVSM A but which cannot be achieved with SVSM B should not be viewed as a desirable feature of the protocol. 

Attestation itself is a generic concept that should be applicable to every SVSM.  Why would anything related to attestation be implemented as specific to a single SVSM architecture?

-Jon

-----Original Message-----
From: AMD-SEV-SNP <amd-sev-snp-bounces+jlange=microsoft.com@lists.suse.com> On Behalf Of Christophe de Dinechin Dupont de Dinechin
Sent: Thursday, January 26, 2023 8:49 AM
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: linux-coco@lists.linux.dev; amd-sev-snp@lists.suse.com
Subject: [EXTERNAL] Re: SVSM Attestation and vTPM specification additions - v0.60



> On 26 Jan 2023, at 15:51, Tom Lendacky <thomas.lendacky@amd.com> wrote:
> 
> On 1/24/23 03:45, Jörg Rödel wrote:
>> On Tue, Jan 10, 2023 at 12:54:27PM -0600, Tom Lendacky wrote:
>>> Attached is an updated draft version of the SVSM specification with 
>>> added support for an attestation protocol and a vTPM protocol as 
>>> well as other miscellaneous changes (all identified by change bar). 
>>> Please take a look and reply with any feedback you may have.
>> Another addition I'd like to propose:
>> It would be nice to have a protocol number reserved for 
>> implementation specific requests. The protocol number only defines 
>> one standardized request to identify the specific SVSM implemenation 
>> in use. Other requests are implementation specific and can be used to 
>> manage the SVSM from the guest.
> 
> Would returning an implementation GUID as part of SVSM_CORE_QUERY_PROTCOL or adding a SVSM_CORE_GET_IMPLEMENTATION call to the core protocol be better? Then we could reserve a range of protocols for use SVSM implementation specific protocols as opposed to just one. Since the protocol ID is 32-bits, maybe make 0x8000_0000 to 0x8FFF_FFFF be SVSM implementation specific.
> 
> Which would folks prefer? A new protocol to retrieve the implementation, modify SVSM_CORE_QUERY_PROTCOL or add SVSM_CORE_GET_IMPLEMENTATION to the core protocol?
> 
> Or any strong feelings about why this wouldn't be good?

Intuitively, I have a slight preference for the reserved range. It is the simplest to understand, has a larger potential for an implementation encoding some info in the protocol, and also means that testing for it can be static (on both sides).

> 
> Thanks,
> Tom
> 
>> One use-case would be, for example, to read the SVSM log buffer from 
>> the guest side, but depending on the implementation there could be 
>> more requests defined.
>> Regards,