Yes, current intel TDP vTPM design only covers ephemeral vTPM solution. It is a known limitation.

I remember we have discussed persistent vTPM before, but we defer it because of complexity.

Is there a full persistent vTPM design ready in coconut-svsm now? E.g. how to protect the vTPM persistent NVS?

Thank you
Yao, Jiewen

-----Original Message-----
From: Reshetova, Elena <elena.reshetova@intel.com>
Sent: Thursday, August 8, 2024 12:05 AM
To: James Bottomley <James.Bottomley@HansenPartnership.com>; Claudio
Siqueira de Carvalho [off-list ref]; dionnaglaze@google.com
Cc: jejb@linux.ibm.com; jroedel@suse.com; Nakajima, Jun
[off-list ref]; Yao, Jiewen [off-list ref];
jpiotrowski@linux.microsoft.com; Dong, Eddie [off-list ref]; Perez,
Ronald [off-list ref]; Lange, Jon [off-list ref]; linux-
coco@lists.linux.dev; Johnson, Simon P [off-list ref]
Subject: RE: Coconut-SVSM - vTPM support for Intel TD Partitioning

quoted

On Wed, 2024-08-07 at 11:28 +0000, Reshetova, Elena wrote:

quoted

quoted

On Tue, 2024-08-06 at 15:51 +0000, Claudio Siqueira de Carvalho
wrote:

quoted

On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:

quoted

quoted

On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:

quoted

quoted

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

[...]

quoted

quoted

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.

If you reinvent the vTPM communication interface, I can see
you
are able to get away without that SVSM communication
component.

The goal is exactly the opposite, i.e. don't reinvent anything,
but
try to stick with exiting ways on how we have been doing things
so
far in Linux. In this light SVSM is an invention to do things.

How will Intel attest the SVSM services provided?

It's in the document they provided at the top of this thread.  I
gave
an analysis here:

https://lore.kernel.org/all/13ea31e26a9891722748c5d6e823f77b6c8b7809.ca

quoted

quoted

mel@HansenPartnership.com/

But basically it's the old trick of using a hash of the public EK
as
the nonce for a TDX atestation report and wrapping it in an EK
certificate.  The problem is it doesn't allow the attesting agent
to
supply the challenge (nonce) so it's not best practice.

As you yourself mentioned earlier, for ephemeral vTPM it is
acceptable. Persistent vTPM has not been in scope of this current
release so the requirement to provision the nonce hasn’t been
there. Again, once Jiewen comes back from the vacation, he can
share his thoughts on how persistent vTPM can be implemented
in the future.

Sure ... the plan was always to do ephemeral first because it's easier.
The best practice comment is what the security guys told me when I
presented the public key hash as nonce scheme.  They can't find an
actual security flaw in it, but they say it's best practice to let the
relying party supply the nonce.

quoted

You keep pointing out the problem of the 'absent nonce': it is not
possible for attesting agent to provide a nonce to be included into
attestation report/quote and saying that we are missing an interface
from the OS guest (L2 guest) to SVSM to supply this nonce to the
SVSM. Is this correct summary? If yes, we have an exiting interface
in Linux OS to ask for the report/quote via configfs-tsm interface
where a fresh nonce (or anything you need) can be provided.

OK, so now I'm confused again.  In order to be reliable, the vTPM
attestation report must provably come only from the SVSM.  With AMD we
can do this because the VMPL level the report was generated at is
included in the signed data, so VMPL0 proves it was from the SVSM.
Nothing prevents the guest from generating an almost identical report
using the attestation APIs, but that report would have VMPL2 as the
reporting level proving it didn't come from the SVSM.

It would work differently in case of TDX. If L2 guest asks for an attestation
report via TDG.MR.REPORT (and provides a nonce), it will generate an
L2 -> L1 exit and no report will be created at this point.
Then L1 can ask for an actual report via once again calling TDG.MR.REPORT
and it has a way to insert anything in the report data, including nonce
from the L2.

quoted

I thought I picked up from the slides that the equivalent Intel scheme
poisons all the RTMRs with a separator before transitioning from the
SVSM to the guest (so after generating the vTPM report)?  Which seems
to indicate that after this is done, even the SVSM can't generate
reports with SVSM provenance any more.

Again, this is the current design of ephemeral vTPM. The spec doesn’t
talk about the persistent case at all.
Above I was only trying to explain how the nonce delivery and asking
for report can work from L2 guest. How you connect it to the persistent
vTPM design needs to be defined still.

quoted

quoted

This interface can be used without modifications from
L2 guest also (with SVSM emulation support of course).
The rest is up to vTPM and SVSM design on how to plug this into
persistent vTPM architecture.

So I'm sure you can come up with a different scheme to identify an SVSM
produced report that will work after it has transitioned to the guest,
but in order to have the SVSM generate the report, you'll still have to
communicate with it (to tell it the nonce and retrieve the report).

Yes, this is exactly what I was trying to explain - it can be done via existing
TDG.MR.REPORT call both in L2 (with L1 assistance) and in L1.

Best Regards,
Elena.

quoted

James