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

[Tom Lendacky <thomas.lendacky@amd.com>]

On 1/10/23 16:14, James Bottomley wrote:
> 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

I wasn't saying it doesn't. I'm saying v1.0 of the SVSM specification 
won't support requests with a non-zero locality since we don't know what a 
non-zero locality means.

But this is a specification for any SVSM, so the current SVSM vTPM is 
relative to what you're working on, but maybe not what someone else is 
working on.

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

I think there would be, though. Right now the call says any non-zero 
locality value returns an error because, as you alluded, there is no 
policing by the SVSM. The API suddenly starting to support non-zero 
localities breaks the API, no?

Thanks,
Tom

> 
> James
>