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

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

On Tue, 2023-01-10 at 16:45 -0600, Tom Lendacky wrote:
> On 1/10/23 16:14, James Bottomley wrote:
[...]
> > 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?

Right, but that makes it a doctor it hurts problem.  Just because we
currently don't know how we'd police locality in the SVSM doesn't mean
an OS upward of us can't.  For instance the current argument about
hibernate keys could be solved by making the linux kernel access the
TPM at a different locality from the one it exposes to user space, so
creation data would definitively tell us if the kernel or a user
created a given TPM key.  Hmm, perhaps I should wire up locality in the
driver ... so the kernel can set it, then we won't fail unexpectedly if
a kernel use case actually comes along. 

James