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

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

> On 31 Jan 2023, at 05:44, Jon Lange <jlange@microsoft.com> wrote:
> 
> Joerg, I'm encouraged to see that we agree about most of the points related to implementation-specific protocol extensions.  It seems like the places where we have yet to come together have less to do with how the standard is defined but about how to approach implementation choices.  That's not really something that can be legislated into a standard (as you suggest) so we'll just have to trust that the right thing happens.
> 
> As far as how to enumerate implementation-specific extensions, why not just embrace the core concept of the protocol's extensibility, which is that individual protocol numbers are optional?  SVSM implementation 1A could propose protocol number 0x123 is its own extensions, and SVSM implementation X could propose protocol number 0xABC as its extensions, etc.  This would eliminate any need to define any first-class concept of implementation identity (thus eliminating the need for an identity registry) and would also eliminate the question of deciding which commands within a given protocol are implemented by a given SVSM.  Instead, a guest OS could query for the implementation protocol it wants, and if it's present, it can use it, and if it is absent, it won't.  A given implementation could choose to lump all of its various implementation-specific extensions into a single protocol, or add a different protocol number for every set of extensions (one for logging, a separate one for other configuration - whatever).  With a 32-bit protocol ID space to choose from, I suspect we don't have to worry too much about running out of IDs quickly, as long as we can construct some logical defense for every separate protocol ID.  And, as a bonus, those individual "implementation-specific" constructs that are easily embraced by another implementation can easily transform into standards without requiring an all-or-nothing adoption of an implementation's complete extension set - from your earlier comments about prototyping, this seems like one of the extensibility features you were hoping to achieve.

This is a common problem in the industry. For example, OpenGL had various extensions that could be queried, each exposing an interface (similar to the protocols here). C and C++ compilers exposed “working group” features or compiler-specific extensions in various ways.

In all cases, some extensions are meant to be and remain “implementation-dependent” whereas others may be work in progress with the intent to become part of the standard later. In OpenGL, GL_NV_draw_vulkan_image would be an example of the former, being specific to NVIDIA, whereas GL_ARB_arrays_of_arrays an example of the latter, ARB standing for Architecture Review Board). Another important aspect is to be able to query the available protocols in a portable way.

With IDs, I would split the ID space into three segments:
- The standard part, which we have today
- The experimental part, to become standard with possibly some changes
- The implementation-dependent part, never to be used by portable code

I must admit that I also thought of logging as an obvious extension to the current protocols, and I was also torn about how to standardize that. The risk of not having an “experimental” part to the ID space is that there will be a lot of discussion and bike shedding before we all agree on something. By contrast, pushing an experiment and having people test it should be comparatively painless.

I’m also considering future changes in the underlying hardware, exposing capabilities that may not exist today. One example that was discussed in another thread is the possibility, some day, to attest not just the guest code, but the host hypervisor and kernel as well. In the AMD case, I suspect this would involve having some of their code running at VMPL0, and maybe having a “VMPL1 SVSM” interface.


Cheers,
Christophe