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

[Jon Lange <jlange@microsoft.com>]

-----Original Message-----
From: Tom Lendacky <thomas.lendacky@amd.com> 
Sent: Tuesday, January 31, 2023 7:07 AM

> I don't think the SVSM specification would be the place to reserve the 
> protocol numbers per implementation. So you would need to still somehow 
> coordinate on what implementations get what protocol range.

Given the size of the protocol ID space, what if we just reserved a range of protocol numbers (say 64K) per known SVSM implementation for that implementation to use as it chooses?  This avoids the problem with a central registry.  We could start by saying that 0x40000000-0x4000FFFF are reserved for the AMD reference implementation, and then as more SVSM implementations come into existence, we could go through a registration process once for each to reserve another range.

> We could just add an optional "identity" protocol with a single call that 
> returns a 16-byte GUID. There should be little to no chance that a GUID 
> would be re-used. The GUID could be used by the guest to know what 
> implementation is being used and what protocols may be available - the 
> query call should still be used to determine their presence. Thoughts?

The downside to an identity-based scheme like this is the "negative implication" of identity: any declaration that "I am FOO" necessarily implies that "I do not support BAR's extensions" (since the meaning of the declaration "I am FOO" is specifically to say "I support FOO's extensions").  One of the stated desires, at least that I observed from the discussion, is the ability to evolve an implementation-specific detail into a standard when doing so is feasible across multiple implementations.  A GUID-based scheme like you suggest will necessarily constrain extensions into implementation-specific choices, which means that if "FOO function #3" becomes an attractive option for standardization, BAR will not be able to make the choice to implement it because BAR would have to declare itself as FOO in order to make "FOO #3" accessible - and that both makes all of the BAR extensions inaccessible, and requires BAR to implement all of the FOO extensions.  That may be OK if we know that 100% of extensions are implementation-specific 100% of the time, but I think that's contrary to the long-term desire.  Contrast this with the range-based scheme described above; if FOO #3 was enumerated as 0x40010003, then a guest could query for that interface and any implementation could choose to expose it regardless of whether it chooses to expose any other FOO-based extensions.

-Jon