Re: SVSM Attestation and vTPM specification additions - v0.60

[Christophe de Dinechin Dupont de Dinechin <cdupontd@redhat.com>]

> 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,