RE: Coconut-SVSM - vTPM support for Intel TD Partitioning

Hi Dionna
Appreciate your valuable feedback!

I will be out of office in next week. As such I will response in next 2 weeks.

In the meantime, please send the list of error you find if possible. We will make sure it fixed in the next version.

Thank you
Yao, Jiewen

-----Original Message-----
From: Dionna Amalie Glaze <redacted>
Sent: Friday, August 2, 2024 1:23 PM
To: Yao, Jiewen <redacted>
Cc: jejb@linux.ibm.com; Jeremi Piotrowski <redacted>;
Claudio Siqueira de Carvalho [off-list ref]; Rödel, Jörg
[off-list ref]; Lange, Jon [off-list ref]; Dong, Eddie
[off-list ref]; Johnson, Simon P [off-list ref];
Reshetova, Elena [off-list ref]; Nakajima, Jun
[off-list ref]; Perez, Ronald [off-list ref]; linux-
coco@lists.linux.dev
Subject: Re: Coconut-SVSM - vTPM support for Intel TD Partitioning

Thanks for this writeup, Jiewen. I see some parallels to the evTPM
paper but some divergences that I find a little curious.

1. The EKpub is ephemeral and fully justified by the TD quote around
it, so there is no need for an X.509 certificate from within the SVSM.
There might be some value for the platform to countersign the EKpub
with some instance information, so if anything I would only consider
the Service CA-signed EK to make sense. The evTPM paper communicates
the "EK cert" by stashing the quote that wraps the EKpub in the NVRAM
index for the EK cert (0x1c00002). Indeed the authors of the paper
already changed Keylime to verify quotes in this form.

By requiring X.509 self-signing, you are now pulling in a bunch of
unnecessary serialization code. For the CA-signed EK, you can get an
X.509 cert in response to a Concise-CSR
https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-
07.html#name-c509-certificate-signing-re
where CBOR serialization is much simpler.

2. I can appreciate the separator events for avoiding an emulation
attack, but this limits your ability to have multiple L2 VMs with
their own vTPMs to be launched at different times. It seems more
appropriate to have a parent key that  each vTPM is underneath, but
I'm not savvy enough with the available hierarchies to know if that
parenting relationship is possible. This would actually make an EKcert
make sense, since it'd be signed by this parent key of the ephemeral
L1VMM. So, not one of your listed options.

This diverges from the evTPM paper since they were targeting SEV-SNP
without nested VMs.

3. Migration isn't discussed much. Do you have a mitigation in mind to
a platform-hosted attack where a migrated VM is cloned? The null
hierarchy seeds would be the same but the VMs would evolve differently
with different traffic and then compromise their security properties.
Maybe the migration TD just accepts a single connection from the
target VM and refuses any extra connection?

4. Clarification question: §2.6 a new paragraph starts with a
reference to a "connection between them" but I'm not sure who the
parties of the "them" are. Is this the connection of the TPM quote to
the TD quote by means of the TD quote containing a hash of the EKpub?
I could also read "them" as L1 and L2.

5. Clarification question: is the presence VMCALL's response HOBs for
the TDVF to add to the hob list for inclusion in the event log so that
there is no need for SVSM to produce an event log? In this case, why
in §2.4 step 3.1 the TDVF creates an event for the SVSM version?
Wouldn't SVSM be the appropriate one to report its version? Not sure
what I missed.

I caught some spelling and grammar errors if you'd like me to send
those off list.

On Thu, Aug 1, 2024 at 3:38 PM Yao, Jiewen [off-list ref] wrote:

quoted

Hi
As follow up, we have drafted the vTPM document and put to

https://github.com/intel-staging/td-partitioning-svsm/blob/svsm-tdp-
vtpm/Documentation/TD%20Partitioning%20based%20virtual%20TPM%20Desig
n%20Guide%20Rev%200.5.1.pdf.

quoted

It describes the current TD Partitioning based vTPM design.

The chapter 5 described the TDVMCALL between L2 guest and L1 VMM, to

detect the presence of L1 vTPM service and initial measurement.

quoted

Please let us know if you have any feedback.

Thank you
Yao, Jiewen

quoted

-----Original Message-----
From: Yao, Jiewen <redacted>
Sent: Thursday, July 4, 2024 11:08 AM
To: jejb@linux.ibm.com; Jeremi Piotrowski

[off-list ref];

quoted

quoted

Claudio Siqueira de Carvalho [off-list ref]; Rödel, Jörg
[off-list ref]
Cc: Lange, Jon <redacted>; Dong, Eddie

[off-list ref];

quoted

quoted

Johnson, Simon P [off-list ref]; Reshetova, Elena
[off-list ref]; Nakajima, Jun [off-list ref];

Perez,

quoted

quoted

Ronald [off-list ref]; linux-coco@lists.linux.dev
Subject: Coconut-SVSM - vTPM support for Intel TD Partitioning

Hi
We posted the initial version of vTPM support for Intel TD Partitioning feature

to

quoted

quoted

https://github.com/intel-staging/td-partitioning-svsm/tree/svsm-tdp-vtpm.

Feature includes:
- vTPM CRB MMIO interface
- vTPM CA generation with TDX remote attestation
- vTPM Endorsement Key certificate and CA provision
- TDP L2 guest vTPM detection through TDVMCALL
- SVSM vTPM startup and measurement (SVSM version and TDVF).
- Ephemeral vTPM NVS

This is initial version and we are working on the improvement.
Any feedback is welcome!


At same time, we find a potential issue https://github.com/coconut-
svsm/svsm/issues/404. If you can take a look and provide your thoughts, that
would be great.

Thank you
Yao, Jiewen

--
-Dionna Glaze, PhD, CISSP, CCSP (she/her)