RE: SVSM vTPM specification

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

On Fri, 2022-10-21 at 16:31 +0000, Jon Lange wrote:
> The drawback to having an identifier-prefixed document is that it
> necessarily restricts each report to providing only a single
> statement from a single SVSM protocol.

Actually, it doesn't.  Nothing prevents a particular type being
multiplexed (although if that happens the report for this particular
type is no-longer self describing).

>   If, in the future, we find it is common for a relying party to
> require, say, five different protocol statements, this imposes a
> requirement to obtain five separate reports.  This means a minimum of
> five round trips from the SVSM to the PSP, which seems
> undesirable.  I think we will really want to invest in defining an
> extensible format that can be placed into a single report.  I'm not
> claiming that JSON is the only option here, but I think we will
> regret any format that prevents extension within a single report.

If this becomes a future problem, we can by all means define a
multiplexed type.  However, absent knowledge that it is a real problem,
I'd like to begin with a simply defined format for the vTPM report plus
room for expansion (the type prefix).

> I'm having a hard time understanding any scenario that involves an
> entity that has access both to an SNP report and the vTPM and which
> also needs to verify the report.  If the objective is for the guest
> (which has access to the vTPM) to obtain the TPM's endorsement key,
> then it could obtain it directly via the vTPM protocol without
> requiring the SNP report.

To my way of thinking, the attestation report proves the binding of a
given vTPM to the SVSM of a given confidential enclave.  I believe this
is required before any relying party can use the TPM and rely on its
measurements. 


>   After all, the vTPM SVSM protocol does not need to be limited to
> providing exactly the functionality of the vTPM command set, but can
> also include other utilities that are useful to the guest.

I think ideally the vTPM should behave like a real TPM.  I agree we
could use extension commands to multiplex SVSM commands over the TPM
interface, but then the standardisation question becomes how?  We could
elect to document these commands in the SVSM interface and hope no-one
tramples on them or go to the TCG and hope to standardise them that
way, but the easiest thing to do is to use the SVSM document to
standardise an SVSM interface to this instead of a TPM one.  Providing
a SVSM interface doesn't preclude providing a TCG extension interface,
so if it's useful (say TDX comes on board) then we can do it later
after we've proven the value with the SVSM interface.

>   If the objective is for an external party to obtain information
> about the vTPM, then it doesn't have access to the vTPM anyway and
> will have to rely solely on what's in the report.  If the vTPM
> endorsement key is rooted to a well-known certificate, then the TPM
> certificate can be provided directly by the guest without relying on
> any SNP report (in exactly the same way that physical TPMs do not
> rely on a separate hardware root of trust to authenticate them).

A TPM certificate can only be trusted if you trust the manufacturing
process of the TPM.  This is fairly well defined for physical TPMs and
known (and regulated) manufacturers, but doesn't really work for pure
software TPMs.

>   Can you shed some light on scenarios in which you think the guest
> has no choice but to compare the SNP report and the vTPM state to
> verify that they match?

An Ephemeral vTPM: the SNP PreAttestation report confirms the code for
the SVSM and OVMF, so you need the OVMF measurements to prove the
kernel, inird and command line and the optional runtime measurements. 
If we get this right the vTPM will provide those measurement, but as a
pre-requisite to relying on those measurements, you need proof that the
vTPM you're relying on is the one within your confidential envelope. 
That's what the report provides by confirming the EK of the ephemeral
vTPM.

James