On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:

quoted

More questions / comments

1.1 "Get TPM AK Cert (signed by EK)". This is something I thought for
a long time too. That's not what the EK does. The EK does not sign
anything. It's used for proving ownership of both EK and AK for
ActivateCredential to get an AKcert from a trusted CA.
What is your intended communication channel between SVSM and a CA for
this credential activation?

Well, that's only if you need a privacy preserving mechanism for
certifying to outside entities.  If you're acting on behalf of the
machine to the machine owner, there's no credible point to the whole
encryption EK, signing AK dance and you might as well use a signing EK.

I just published tools for allowing certification of the null seed used
by the kernel for session salting:

https://lore.kernel.org/linux-integrity/20240802202606.12767-1-
James.Bottomley@HansenPartnership.com

And it uses a signing EK for similar reasons (it's long lived and there
are no privacy concerns if it acts solely for the machine owner).

quoted

2.2.2 item 6, migration needs to ensure that the vTPM state is not
duplicated, which is a possible host attack by spinning up two
targets and directing migration to both. This needs to be explicitly
required for TPM security.
2.2.3 item 8 I don't think the community has fully agreed that MMIO
should be the command pathway for SVSM-based vTPM due to

performance

quoted

problems. This appears to disallow an SVSM service call
implementation as an enlightenment path.

Well, no, for the AMD SNP SVSM an enlightened TPM interface makes the
most sense because everything else is enlightened.

That brings me to a curious point: is the Intel TDX SVSM going to
follow the SVSM protocol interface?  because if it is, it will
naturally inherit the enlightened interface (the code will be present
in the kernel, so it only needs activating).  However, if the Intel
SVSM were going to ignore the SVSM protocol spec then it would have to
reinvent everything and the CRB interface might make more sense.

I cannot speak on behalf of the Intel TDX *SVSM* implementation, but for the
Linux guest kernel there is no intention at the moment to support smth
like SVSM protocol interface. We have made an evaluation on this during
the spring. There are no usecases currently that require such new protocol
introduction on Intel TDX and it does bring additional code complexity, etc.
If anyone believes otherwise, please let me know. 

Best Regards,
Elena. 

Regards,

James