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

[James Bottomley <jejb@linux.ibm.com>]

On Tue, 2023-01-10 at 15:03 -0600, Tom Lendacky wrote:
> On 1/10/23 13:40, Dionna Amalie Glaze wrote:
> > typo: "oridnal"
> 
> Will fix.
> 
> > 
> > For the statement "Locality usage for the vTPM is not currently
> > defined." should this be interpreted as version 1 of the vTPM
> > protocol will not support locality, or simply that version 1 might
> > have the affordance to add behavior for non-zero locality in a
> > future revision of version 1, such that the result is not specified
> > as SVSM_ERR_INVALID_PARAMETER? I think the latter is probably a
> > dangerous interpretation unless v0.60 of this document is strictly
> > considered "unstable" and shouldn't be used upstream, so I'd
> > recommend clarifying that "currently" in a document that might
> > later be outdated should be precise about its specified behavior in
> > a versioned fashion.
> 
> Version 1 of the vTPM protocol will not support locality, so I'll
> remove the "currently." If locality is to be supported, it would be
> in a post version 1 of the vTPM protocol and will likely require
> invoking a new call id (unless we somehow manage to figure out
> locality before v1.0 of the SVSM specification).

Actually, that's not entirely correct:  The current SVSM vTPM
implements locality as a number just fine.  However, if all TPM
consumers can access all localities without restriction locality
becomes a totally useless thing.  To give a meaning to locality, you
have to have some restrictions about how components can access it.  The
only current user of localities I know is dynamic launch and that's
usually done by restricting locality 4 to the CPU microcode in a
physical system.

Until we can agree what dynamic launch (or some other locality
consumer) might mean in a confidential VM (and that the SVSM can police
it) there's no real point wiring locality up in the linux kernel
driver.  I mean the linux kernel itself doesn't use localities either,
it just sets them to 0 unless the TPM indicates a different default
value.

If we do find a use for localites, whatever we use them for would be
described by TPM event log entries, so there would be no need of a new
versioned SVSM call.

James