question on vTPM interface in coconut-svsm

question on vTPM interface in coconut-svsm

[Yao, Jiewen]

Hello
Since Intel is planning to use coconut-svsm [1] for TD-partitioning, I am evaluating the vTPM support for coconut-svsm and L2-Guest for Intel TDX. As EDKII SecurityPkg and OvmfPkg maintainer, I am also evaluating the impact to EDKII project [2].

Currently, the PR for vTPM in coconut-svsm [3] is using the AMD SVSM defined vTPM protocol - SVSM_VTPM_CMD Call [4]. It is a brand new communication mechanism. As such, we need a special SVSM vTPM driver in EDKII OVMF[5] and Linux Guest [6].

At same time, we have also prototyped vTPM support for TD-partitioning based on coconut-svsm [1]. For vTPM interface, we just reused the original TCG defined CRB interface in TCG PTP specification [7]. 
We modified coconut-svsm to provide TPM CRB device model + TPM2 library reference code. It is similar to [3]. The only difference is that we don't use vTPM protocol [4], but use TPM CRB interface [7].
We mapped the TPM CRB MMIO (0xfed40000) as private MMIO which is only accessible between trusted L1-VMM (coconut-SVSM) and L2-Guest (Linux). The untrusted host VMM cannot access the TPM CRB MMIO.
The TPM CRB interface is reported via TCG defined TPM2 ACPI table [8]. The TPM2 ACPI table exposes StartMethod as EFI_TPM2_ACPI_TABLE_START_METHOD_COMMAND_RESPONSE_BUFFER_INTERFACE (6), see [9]. And we don't need _DSM for StartMethod, see [10].
After those change, we can run vTPM in OVMF and Linux Guest successfully on top of coconut-SVSM, with minimal change on TPM device driver.

Questions:
With this POC, it seems TCG CRB interface [7] is a feasible option for vTPM in coconut-svsm. We are NOT clear what is the motivation to have a new vTPM protocol [4].
Would you please educate us on that? Why not reuse TCG CRB interface [7], but introduce a new one [4]?

What is opinion from Linux TPM driver maintainer? I believe we would like to align for vTPM support in EDKII and Linux.

References:
[1] coconut-svsm, https://github.com/coconut-svsm/svsm
[2] EDKII project, https://github.com/tianocore/edk2
[3] coconut-svsm, vTPM in svsm, https://github.com/coconut-svsm/svsm/pull/135
[4] AMD, SVSM for SEV-SNP guest, https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/58019.pdf
[5] coconut-svsm, vTPM update in EDKII OVMF, https://github.com/coconut-svsm/edk2/pull/2/commits/ca0e644c1661c4ad10c2533dc3c360faa203625e 
[6] coconut-svsm, vTPM update in Linux Guest, https://lore.kernel.org/all/826af61ac2097a14eee0d81cb869eba9c4fdef8b.camel@linux.ibm.com/, https://lore.kernel.org/all/20c7dda843f93b22f6c6afca3820a53d669503bf.camel@linux.ibm.com/, https://lore.kernel.org/all/83bcfc398d885f9e42d5aae42359fe02ab12d306.camel@linux.ibm.com/
[7] TCG PTP Specification, https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
[8] TCG ACPI Specification, https://trustedcomputinggroup.org/resource/tcg-acpi-specification/
[9] EDKII, TPM - TPM2 ACPI table, https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.c
[10] EDKII, TPM - DSDT ACPI table, https://github.com/tianocore/edk2/blob/master/SecurityPkg/Tcg/Tcg2Acpi/Tpm.asl


Thank you
Yao, Jiewen

RE: question on vTPM interface in coconut-svsm

[Reshetova, Elena]

> Hello
> Since Intel is planning to use coconut-svsm [1] for TD-partitioning, I am evaluating
> the vTPM support for coconut-svsm and L2-Guest for Intel TDX. As EDKII
> SecurityPkg and OvmfPkg maintainer, I am also evaluating the impact to EDKII
> project [2].
> 
> Currently, the PR for vTPM in coconut-svsm [3] is using the AMD SVSM defined
> vTPM protocol - SVSM_VTPM_CMD Call [4]. It is a brand new communication
> mechanism. As such, we need a special SVSM vTPM driver in EDKII OVMF[5] and
> Linux Guest [6].
> 
> At same time, we have also prototyped vTPM support for TD-partitioning based
> on coconut-svsm [1]. For vTPM interface, we just reused the original TCG defined
> CRB interface in TCG PTP specification [7].
> We modified coconut-svsm to provide TPM CRB device model + TPM2 library
> reference code. It is similar to [3]. The only difference is that we don’t use vTPM
> protocol [4], but use TPM CRB interface [7].
> We mapped the TPM CRB MMIO (0xfed40000) as private MMIO which is only
> accessible between trusted L1-VMM (coconut-SVSM) and L2-Guest (Linux). The
> untrusted host VMM cannot access the TPM CRB MMIO.
> The TPM CRB interface is reported via TCG defined TPM2 ACPI table [8]. The
> TPM2 ACPI table exposes StartMethod as
> EFI_TPM2_ACPI_TABLE_START_METHOD_COMMAND_RESPONSE_BUFFER_INTER
> FACE (6), see [9]. And we don’t need _DSM for StartMethod, see [10].
> After those change, we can run vTPM in OVMF and Linux Guest successfully on
> top of coconut-SVSM, with minimal change on TPM device driver.
> 
> Questions:
> With this POC, it seems TCG CRB interface [7] is a feasible option for vTPM in
> coconut-svsm. We are NOT clear what is the motivation to have a new vTPM
> protocol [4].
> Would you please educate us on that? Why not reuse TCG CRB interface [7], but
> introduce a new one [4]?
> 
> What is opinion from Linux TPM driver maintainer? I believe we would like to
> align for vTPM support in EDKII and Linux.

To go one step further, it is important to note that while the current #1 usecase
is vTPM, we can envision in the future other devices that coconut-svsm might
emulate for security purposes. So, whatever direction we decide here, it must
be scalable and acceptable beyond just TPM usecase/maintainers. 

For example, are we ready to commit to write and support a new set of Linux/EDKII
drivers for any existing device that someone's security usecase/deployment might
require to be now emulated in coconut-svsm? Or do we want to develop a secure
way to use the existing drivers for what is essentially the same device (function-wise),
but emulated by different environments?
Both choices are possible and each has its own set of tradeoffs that we must discuss imo. 

Best Regards,
Elena. 

Re: question on vTPM interface in coconut-svsm

[Joerg Roedel]

Hi Elena,

In the end COCONUT-SVSM will support both modes, emulating devices for enlightened OSes which require those to implement an SVSM specific protocol and the unenlightened OS (paravisor) mode where the SVSM emulates the interfaces of real devices.

Which devices to emulate in which mode and what mode specific emulations support is another question, though.

Regards,

Jörg

> Am 28.03.2024 um 09:11 schrieb Reshetova, Elena <elena.reshetova@intel.com>:
> 
>> Hello
>> Since Intel is planning to use coconut-svsm [1] for TD-partitioning, I am evaluating
>> the vTPM support for coconut-svsm and L2-Guest for Intel TDX. As EDKII
>> SecurityPkg and OvmfPkg maintainer, I am also evaluating the impact to EDKII
>> project [2].
>> 
>> Currently, the PR for vTPM in coconut-svsm [3] is using the AMD SVSM defined
>> vTPM protocol - SVSM_VTPM_CMD Call [4]. It is a brand new communication
>> mechanism. As such, we need a special SVSM vTPM driver in EDKII OVMF[5] and
>> Linux Guest [6].
>> 
>> At same time, we have also prototyped vTPM support for TD-partitioning based
>> on coconut-svsm [1]. For vTPM interface, we just reused the original TCG defined
>> CRB interface in TCG PTP specification [7].
>> We modified coconut-svsm to provide TPM CRB device model + TPM2 library
>> reference code. It is similar to [3]. The only difference is that we don’t use vTPM
>> protocol [4], but use TPM CRB interface [7].
>> We mapped the TPM CRB MMIO (0xfed40000) as private MMIO which is only
>> accessible between trusted L1-VMM (coconut-SVSM) and L2-Guest (Linux). The
>> untrusted host VMM cannot access the TPM CRB MMIO.
>> The TPM CRB interface is reported via TCG defined TPM2 ACPI table [8]. The
>> TPM2 ACPI table exposes StartMethod as
>> EFI_TPM2_ACPI_TABLE_START_METHOD_COMMAND_RESPONSE_BUFFER_INTER
>> FACE (6), see [9]. And we don’t need _DSM for StartMethod, see [10].
>> After those change, we can run vTPM in OVMF and Linux Guest successfully on
>> top of coconut-SVSM, with minimal change on TPM device driver.
>> 
>> Questions:
>> With this POC, it seems TCG CRB interface [7] is a feasible option for vTPM in
>> coconut-svsm. We are NOT clear what is the motivation to have a new vTPM
>> protocol [4].
>> Would you please educate us on that? Why not reuse TCG CRB interface [7], but
>> introduce a new one [4]?
>> 
>> What is opinion from Linux TPM driver maintainer? I believe we would like to
>> align for vTPM support in EDKII and Linux.
> 
> To go one step further, it is important to note that while the current #1 usecase
> is vTPM, we can envision in the future other devices that coconut-svsm might
> emulate for security purposes. So, whatever direction we decide here, it must
> be scalable and acceptable beyond just TPM usecase/maintainers. 
> 
> For example, are we ready to commit to write and support a new set of Linux/EDKII
> drivers for any existing device that someone's security usecase/deployment might
> require to be now emulated in coconut-svsm? Or do we want to develop a secure
> way to use the existing drivers for what is essentially the same device (function-wise),
> but emulated by different environments?
> Both choices are possible and each has its own set of tradeoffs that we must discuss imo. 
> 
> Best Regards,
> Elena. 

Re: question on vTPM interface in coconut-svsm

[James Bottomley]

On Thu, 2024-03-28 at 06:29 +0000, Yao, Jiewen wrote:
[...]
> At same time, we have also prototyped vTPM support for TD-
> partitioning based on coconut-svsm [1]. For vTPM interface, we just
> reused the original TCG defined CRB interface in TCG PTP
> specification [7]. 

If I could ask: where's the code for this?  We also did a CRB prototype
for the first papers on SVSM vTPM:

https://dl.acm.org/doi/abs/10.1145/3627106.3627112

But we found several difficulties with the CRB interface that doing a
platform one overcomes.

> We modified coconut-svsm to provide TPM CRB device model + TPM2
> library reference code. It is similar to [3]. The only difference is
> that we don't use vTPM protocol [4], but use TPM CRB interface [7].
> We mapped the TPM CRB MMIO (0xfed40000) as private MMIO which is only
> accessible between trusted L1-VMM (coconut-SVSM) and L2-Guest
> (Linux).

So how do you do this? we had the CRB ACPI tables set up by QEMU for
the above, which requires modifying QEMU to provide the TPM description
but not activate any backend interface (i.e. a new configuration flag).

The second problem is that ACPI described regions are by default, being
device buffers, shared not private (i.e. anyone can snoop the TPM
commands).  You can modify the OS to override this, but then you need a
very specific recognition of the TPM as being provided by the SVSM not
QEMU otherwise you'll block any emulated or real CRB TPM device when
total memory encryption is enabled.

Finally the start mechanisms are bit or ASL method based.  The bit
based one is just too much overhead if you handle the fault in the SVSM
and the start method doesn't provide enough sophistication to activate
the SVSM entry protocol.  We eventually modified the CRB driver to do
the SVSM start but, again, this is hard to reconcile with a standard
CRB interface.

>  The untrusted host VMM cannot access the TPM CRB MMIO.
> The TPM CRB interface is reported via TCG defined TPM2 ACPI table
> [8]. The TPM2 ACPI table exposes StartMethod as
> EFI_TPM2_ACPI_TABLE_START_METHOD_COMMAND_RESPONSE_BUFFER_INTERFACE
> (6), see [9]. And we don't need _DSM for StartMethod, see [10].

So publishing the code for this would allow us to evaluate whether it
might work for SEV-SNP as well but our experience above tells us it was
a lot of code modification in the OS and QEMU and even more (which we
didn't do) to make the CRB driver still work with non-SVSM devices,
which is why it's easier to do a small and simple platform device which
requires small OS modifications, no QEMU changes and an easy attach
when the SVSM is present.

James

Re: question on vTPM interface in coconut-svsm

[Jeremi Piotrowski]

On 28/03/2024 13:03, James Bottomley wrote:
> On Thu, 2024-03-28 at 06:29 +0000, Yao, Jiewen wrote:
> [...]
>> At same time, we have also prototyped vTPM support for TD-
>> partitioning based on coconut-svsm [1]. For vTPM interface, we just
>> reused the original TCG defined CRB interface in TCG PTP
>> specification [7]. 
> 
> If I could ask: where's the code for this?  We also did a CRB prototype
> for the first papers on SVSM vTPM:
> 
> https://dl.acm.org/doi/abs/10.1145/3627106.3627112
> 
> But we found several difficulties with the CRB interface that doing a
> platform one overcomes.
> 
>> We modified coconut-svsm to provide TPM CRB device model + TPM2
>> library reference code. It is similar to [3]. The only difference is
>> that we don't use vTPM protocol [4], but use TPM CRB interface [7].
>> We mapped the TPM CRB MMIO (0xfed40000) as private MMIO which is only
>> accessible between trusted L1-VMM (coconut-SVSM) and L2-Guest
>> (Linux).
> 
> So how do you do this? we had the CRB ACPI tables set up by QEMU for
> the above, which requires modifying QEMU to provide the TPM description
> but not activate any backend interface (i.e. a new configuration flag).
> 
> The second problem is that ACPI described regions are by default, being
> device buffers, shared not private (i.e. anyone can snoop the TPM
> commands).  You can modify the OS to override this, but then you need a
> very specific recognition of the TPM as being provided by the SVSM not
> QEMU otherwise you'll block any emulated or real CRB TPM device when
> total memory encryption is enabled.
> 
> Finally the start mechanisms are bit or ASL method based.  The bit
> based one is just too much overhead if you handle the fault in the SVSM
> and the start method doesn't provide enough sophistication to activate
> the SVSM entry protocol.  We eventually modified the CRB driver to do
> the SVSM start but, again, this is hard to reconcile with a standard
> CRB interface.
> 
>>  The untrusted host VMM cannot access the TPM CRB MMIO.
>> The TPM CRB interface is reported via TCG defined TPM2 ACPI table
>> [8]. The TPM2 ACPI table exposes StartMethod as
>> EFI_TPM2_ACPI_TABLE_START_METHOD_COMMAND_RESPONSE_BUFFER_INTERFACE
>> (6), see [9]. And we don't need _DSM for StartMethod, see [10].
> 
> So publishing the code for this would allow us to evaluate whether it
> might work for SEV-SNP as well but our experience above tells us it was
> a lot of code modification in the OS and QEMU and even more (which we
> didn't do) to make the CRB driver still work with non-SVSM devices,
> which is why it's easier to do a small and simple platform device which
> requires small OS modifications, no QEMU changes and an easy attach
> when the SVSM is present.
> 
> James
> 

Azure ships the configuration described above for SEV-SNP (and TDX). The TPM is
implemented in an "SVSM"(paravisor), exposed through TPM CRB MMIO. The
kernel has a callback informing ioremap which MMIO addresses should be
considered shared/private [1]. This is the Hyper-v implementation of that
callback: [2].

So it can work if you detect it like this:

if (SEV_SNP_GUEST && SVSM_PRESENT && SVSM_PROVIDES_VTPM)
   // vtpm should be mapped private

Jeremi

[1]: https://lore.kernel.org/lkml/1678329614-3482-2-git-send-email-mikelley@microsoft.com/
[2]: https://elixir.bootlin.com/linux/latest/source/arch/x86/hyperv/ivm.c#L610

Re: question on vTPM interface in coconut-svsm

[James Bottomley]

On Thu, 2024-03-28 at 13:22 +0100, Jeremi Piotrowski wrote:
[...]
> Azure ships the configuration described above for SEV-SNP (and TDX).
> The TPM is implemented in an "SVSM"(paravisor), exposed through TPM
> CRB MMIO. The kernel has a callback informing ioremap which MMIO
> addresses should be considered shared/private [1]. This is the Hyper-
> v implementation of that callback: [2].
> 
> So it can work if you detect it like this:
> 
> if (SEV_SNP_GUEST && SVSM_PRESENT && SVSM_PROVIDES_VTPM)
>    // vtpm should be mapped private

Well, yes, it's pretty much identical to the detection mechanism used
to activate the platform TPM driver:

https://lore.kernel.org/all/83bcfc398d885f9e42d5aae42359fe02ab12d306.camel@linux.ibm.com/

The SVSM_PROVIDES_VTPM is actually a dynamic probe to find the vTPM
protocol inside the SVSM.

So what's the mechanism hyper-v uses to start a CRB command?

James

Re: question on vTPM interface in coconut-svsm

[Jeremi Piotrowski]

On 28/03/2024 13:33, James Bottomley wrote:
> On Thu, 2024-03-28 at 13:22 +0100, Jeremi Piotrowski wrote:
> [...]
>> Azure ships the configuration described above for SEV-SNP (and TDX).
>> The TPM is implemented in an "SVSM"(paravisor), exposed through TPM
>> CRB MMIO. The kernel has a callback informing ioremap which MMIO
>> addresses should be considered shared/private [1]. This is the Hyper-
>> v implementation of that callback: [2].
>>
>> So it can work if you detect it like this:
>>
>> if (SEV_SNP_GUEST && SVSM_PRESENT && SVSM_PROVIDES_VTPM)
>>    // vtpm should be mapped private
> 
> Well, yes, it's pretty much identical to the detection mechanism used
> to activate the platform TPM driver:
> 
> https://lore.kernel.org/all/83bcfc398d885f9e42d5aae42359fe02ab12d306.camel@linux.ibm.com/
> 
> The SVSM_PROVIDES_VTPM is actually a dynamic probe to find the vTPM
> protocol inside the SVSM.
> 
> So what's the mechanism hyper-v uses to start a CRB command?
> 
> James
> 

Do you mean start method? The VTPM uses ACPI_TPM2_COMMAND_BUFFER, the guest sees a
TPM2 ACPI table, maps the control address as private and then the tpm_crb driver
just works.

Jeremi

Re: question on vTPM interface in coconut-svsm

[James Bottomley]

On Thu, 2024-03-28 at 14:41 +0100, Jeremi Piotrowski wrote:
> On 28/03/2024 13:33, James Bottomley wrote:
> > On Thu, 2024-03-28 at 13:22 +0100, Jeremi Piotrowski wrote:
> > [...]
> > > Azure ships the configuration described above for SEV-SNP (and
> > > TDX).
> > > The TPM is implemented in an "SVSM"(paravisor), exposed through
> > > TPM
> > > CRB MMIO. The kernel has a callback informing ioremap which MMIO
> > > addresses should be considered shared/private [1]. This is the
> > > Hyper-
> > > v implementation of that callback: [2].
> > > 
> > > So it can work if you detect it like this:
> > > 
> > > if (SEV_SNP_GUEST && SVSM_PRESENT && SVSM_PROVIDES_VTPM)
> > >    // vtpm should be mapped private
> > 
> > Well, yes, it's pretty much identical to the detection mechanism
> > used
> > to activate the platform TPM driver:
> > 
> > https://lore.kernel.org/all/83bcfc398d885f9e42d5aae42359fe02ab12d306.camel@linux.ibm.com/
> > 
> > The SVSM_PROVIDES_VTPM is actually a dynamic probe to find the vTPM
> > protocol inside the SVSM.
> > 
> > So what's the mechanism hyper-v uses to start a CRB command?
> > 
> > James
> > 
> 
> Do you mean start method? The VTPM uses ACPI_TPM2_COMMAND_BUFFER, the
> guest sees a TPM2 ACPI table, maps the control address as private and
> then the tpm_crb driver just works.

Not without help.  The usual method of starting a CRB command is to
write the command buffer and length into the CRB registers and then set
the start bit (a real CRB device monitors the control area).  Since
they're all in the same page, you can emulate what a real device does
by unmapping this area in the guest kernel and getting the SVSM to
intercept the writes, in which case you see a lot to fix up and quite a
number of VMEXITs per command, or you can ignore this region and use
some type of ASL start mechanism instead, which means only one VMEXIT.
What does hyper-v do?

James

Re: question on vTPM interface in coconut-svsm

[Jeremi Piotrowski]

On 28/03/2024 14:54, James Bottomley wrote:
> On Thu, 2024-03-28 at 14:41 +0100, Jeremi Piotrowski wrote:
>> On 28/03/2024 13:33, James Bottomley wrote:
>>> On Thu, 2024-03-28 at 13:22 +0100, Jeremi Piotrowski wrote:
>>> [...]
>>>> Azure ships the configuration described above for SEV-SNP (and
>>>> TDX).
>>>> The TPM is implemented in an "SVSM"(paravisor), exposed through
>>>> TPM
>>>> CRB MMIO. The kernel has a callback informing ioremap which MMIO
>>>> addresses should be considered shared/private [1]. This is the
>>>> Hyper-
>>>> v implementation of that callback: [2].
>>>>
>>>> So it can work if you detect it like this:
>>>>
>>>> if (SEV_SNP_GUEST && SVSM_PRESENT && SVSM_PROVIDES_VTPM)
>>>>    // vtpm should be mapped private
>>>
>>> Well, yes, it's pretty much identical to the detection mechanism
>>> used
>>> to activate the platform TPM driver:
>>>
>>> https://lore.kernel.org/all/83bcfc398d885f9e42d5aae42359fe02ab12d306.camel@linux.ibm.com/
>>>
>>> The SVSM_PROVIDES_VTPM is actually a dynamic probe to find the vTPM
>>> protocol inside the SVSM.
>>>
>>> So what's the mechanism hyper-v uses to start a CRB command?
>>>
>>> James
>>>
>>
>> Do you mean start method? The VTPM uses ACPI_TPM2_COMMAND_BUFFER, the
>> guest sees a TPM2 ACPI table, maps the control address as private and
>> then the tpm_crb driver just works.
> 
> Not without help.  The usual method of starting a CRB command is to
> write the command buffer and length into the CRB registers and then set
> the start bit (a real CRB device monitors the control area).  Since
> they're all in the same page, you can emulate what a real device does
> by unmapping this area in the guest kernel and getting the SVSM to
> intercept the writes, in which case you see a lot to fix up and quite a
> number of VMEXITs per command, or you can ignore this region and use
> some type of ASL start mechanism instead, which means only one VMEXIT.
> What does hyper-v do?
> 
> James

Now I get it, thanks. It's based on intercepting writes.

Jeremi

Coconut-SVSM - vTPM support for Intel TD Partitioning

[Yao, Jiewen]

Hi
We posted the initial version of vTPM support for Intel TD Partitioning feature to 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

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

[Yao, Jiewen]

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%20Design%20Guide%20Rev%200.5.1.pdf.
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.
Please let us know if you have any feedback.

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Yao, Jiewen <jiewen.yao@intel.com>
> Sent: Thursday, July 4, 2024 11:08 AM
> To: jejb@linux.ibm.com; Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>;
> Claudio Siqueira de Carvalho <cclaudio@ibm.com>; Rödel, Jörg
> <jroedel@suse.com>
> Cc: Lange, Jon <jlange@microsoft.com>; Dong, Eddie <eddie.dong@intel.com>;
> Johnson, Simon P <simon.p.johnson@intel.com>; Reshetova, Elena
> <elena.reshetova@intel.com>; Nakajima, Jun <jun.nakajima@intel.com>; Perez,
> Ronald <ronald.perez@intel.com>; 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
> 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

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

[Dionna Amalie Glaze]

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 <jiewen.yao@intel.com> wrote:
>
> 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%20Design%20Guide%20Rev%200.5.1.pdf.
> 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.
> Please let us know if you have any feedback.
>
> Thank you
> Yao, Jiewen
>
> > -----Original Message-----
> > From: Yao, Jiewen <jiewen.yao@intel.com>
> > Sent: Thursday, July 4, 2024 11:08 AM
> > To: jejb@linux.ibm.com; Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>;
> > Claudio Siqueira de Carvalho <cclaudio@ibm.com>; Rödel, Jörg
> > <jroedel@suse.com>
> > Cc: Lange, Jon <jlange@microsoft.com>; Dong, Eddie <eddie.dong@intel.com>;
> > Johnson, Simon P <simon.p.johnson@intel.com>; Reshetova, Elena
> > <elena.reshetova@intel.com>; Nakajima, Jun <jun.nakajima@intel.com>; Perez,
> > Ronald <ronald.perez@intel.com>; 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
> > 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)

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

[Yao, Jiewen]

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 <dionnaglaze@google.com>
> Sent: Friday, August 2, 2024 1:23 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: jejb@linux.ibm.com; Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>;
> Claudio Siqueira de Carvalho <cclaudio@ibm.com>; Rödel, Jörg
> <jroedel@suse.com>; Lange, Jon <jlange@microsoft.com>; Dong, Eddie
> <eddie.dong@intel.com>; Johnson, Simon P <simon.p.johnson@intel.com>;
> Reshetova, Elena <elena.reshetova@intel.com>; Nakajima, Jun
> <jun.nakajima@intel.com>; Perez, Ronald <ronald.perez@intel.com>; 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 <jiewen.yao@intel.com> wrote:
> >
> > 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.
> > 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.
> > Please let us know if you have any feedback.
> >
> > Thank you
> > Yao, Jiewen
> >
> > > -----Original Message-----
> > > From: Yao, Jiewen <jiewen.yao@intel.com>
> > > Sent: Thursday, July 4, 2024 11:08 AM
> > > To: jejb@linux.ibm.com; Jeremi Piotrowski
> <jpiotrowski@linux.microsoft.com>;
> > > Claudio Siqueira de Carvalho <cclaudio@ibm.com>; Rödel, Jörg
> > > <jroedel@suse.com>
> > > Cc: Lange, Jon <jlange@microsoft.com>; Dong, Eddie
> <eddie.dong@intel.com>;
> > > Johnson, Simon P <simon.p.johnson@intel.com>; Reshetova, Elena
> > > <elena.reshetova@intel.com>; Nakajima, Jun <jun.nakajima@intel.com>;
> Perez,
> > > Ronald <ronald.perez@intel.com>; 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
> > > 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)

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

[James Bottomley]

On Thu, 2024-08-01 at 22:38 +0000, Yao, Jiewen wrote:
> 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%20Design%20Guide%20Rev%200.5.1.pdf
> .
> It describes the current TD Partitioning based vTPM design.

So this design follows what was in the ephemeral vTPM paper

https://dl.acm.org/doi/abs/10.1145/3627106.3627112

and is what IBM demoed at LPC.  However, the weakness in this design is
that there's no challenge for the platform attestation used in place of
the EK certificate.  We tried to argue around that because the
ephemeral EK changes on every boot and should thus mitigate any replay
concerns, but that can't extend to a stateful vTPM and we needed to
support both (and letting the attesting party provide the nonce even in
terms of the EK hash is still not good security practice).  That's why
the SVSM API includes a vTPM attestation protocol that allows the
external verifier to provide a nonce and dispenses with the EK cert
emulation protocol.

Regards,

James

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

[James Bottomley]

On Thu, 2024-08-01 at 22:38 +0000, Yao, Jiewen wrote:
> 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%20Design%20Guide%20Rev%200.5.1.pdf
> .

Just a note for the vTPM reference implementation which, I think,
applies to both you and the current SVSM-vTPM: the reference TPM
implementation has moved to

https://github.com/TrustedComputingGroup/TPM

And the one you list (https://github.com/microsoft/ms-tpm-20-ref) is
now a stale copy that isn't being kept up to date.

Regards,

James

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

[Dionna Amalie Glaze]

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?

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
problems. This appears to disallow an SVSM service call implementation
as an enlightenment path.
2.4 the alternate entrypoint TD_PARAM is undocumented. Please add a
footnote that this will be in a future revision to the TDX module
reference.
item 2.1 The launch parameter (TD_HOB) is currently measured to MRTD,
so how is this data communicated to SVSM if it's meant to be measured
to RTMR[0] (and be a useful measurement, presumably because it wasn't
measured to MRTD?)

2.5.2 "TPM CRB interface attack" and "TPM command attack" could use
citations for what you mean.

On Fri, Aug 2, 2024 at 8:40 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Thu, 2024-08-01 at 22:38 +0000, Yao, Jiewen wrote:
> > 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%20Design%20Guide%20Rev%200.5.1.pdf
> > .
>
> Just a note for the vTPM reference implementation which, I think,
> applies to both you and the current SVSM-vTPM: the reference TPM
> implementation has moved to
>
> https://github.com/TrustedComputingGroup/TPM
>
> And the one you list (https://github.com/microsoft/ms-tpm-20-ref) is
> now a stale copy that isn't being kept up to date.
>
> Regards,
>
> James
>
>


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

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

[James Bottomley]

On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> 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).

> 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
> 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.

Regards,

James

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

[Reshetova, Elena]

> On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > 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).
> 
> > 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
> > 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

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

[James Bottomley]

On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
[...]
> > 
> > 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. I assume
you've done the same for other SVSM provided services like
deposit/remove memory and vcpu create/delete, but what about migration
when it comes along?  Since the high level operations will be pretty
much identical on AMD and Intel it would be very annoying to have to do
it in completely different ways (with presumably different tools).

Regards,

James

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

[Reshetova, Elena]

> On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> [...]
> > >
> > > 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.


 I assume
> you've done the same for other SVSM provided services like
> deposit/remove memory and vcpu create/delete, but what about migration
> when it comes along? 

Could you please give an example of where let's say we are not ok with
existing Linux ways of depositing/removing memory? Why do we need
to create a new protocol like SVSM from guest kernel for doing this?
It can be done if there is a valid usecase of course. All I am saying is that
we haven’t found any yet.

 Since the high level operations will be pretty
> much identical on AMD and Intel it would be very annoying to have to do
> it in completely different ways (with presumably different tools).

Migration is a separate story, which i dont think has any conclusion yet
or agreement in the community. We (Intel TDX) have a way to migrate
the guest without the guest assistance, so we dont have a strict requirement
to migrate out of SVSM. It remains to be seen what method(s) is to be 
selected at the end. And if svsm-based migration method is going to be
supported for intel tdx, then it needs a separate analysis to determine
what is the actual required communication between the L2 guest and
SVSM in our case and whenever the usage of the SVSM-style protocol
is necessary.  

Imo migration is one of the topics that would be great to discuss at LPC.

Best Regards,
Elena. 

> 
> Regards,
> 
> James

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

[Claudio Siqueira de Carvalho]

On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > [...]
> > > > 
> > > > 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? In addition to the core
protocol and the VTPM protocol, the SVSM spec 1.0 also define the ATTEST
protocol which can be used to get an attestation report for the SVSM services,
endorsing the supported services and their respective payloads. The payload for
the VTPM service is the SVSM-vTPM EK pub.

Regards,
Claudio

> 
> 
>  I assume
> > you've done the same for other SVSM provided services like
> > deposit/remove memory and vcpu create/delete, but what about migration
> > when it comes along? 
> 
> Could you please give an example of where let's say we are not ok with
> existing Linux ways of depositing/removing memory? Why do we need
> to create a new protocol like SVSM from guest kernel for doing this?
> It can be done if there is a valid usecase of course. All I am saying is that
> we haven’t found any yet.
> 
>  Since the high level operations will be pretty
> > much identical on AMD and Intel it would be very annoying to have to do
> > it in completely different ways (with presumably different tools).
> 
> Migration is a separate story, which i dont think has any conclusion yet
> or agreement in the community. We (Intel TDX) have a way to migrate
> the guest without the guest assistance, so we dont have a strict requirement
> to migrate out of SVSM. It remains to be seen what method(s) is to be 
> selected at the end. And if svsm-based migration method is going to be
> supported for intel tdx, then it needs a separate analysis to determine
> what is the actual required communication between the L2 guest and
> SVSM in our case and whenever the usage of the SVSM-style protocol
> is necessary.  
> 
> Imo migration is one of the topics that would be great to discuss at LPC.
> 
> Best Regards,
> Elena. 
> 
> > 
> > Regards,
> > 
> > James
> 

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

[James Bottomley]

On Tue, 2024-08-06 at 15:51 +0000, Claudio Siqueira de Carvalho wrote:
> On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > > [...]
> > > > > 
> > > > > 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.camel@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.

Regards,

James

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

[Reshetova, Elena]

> On Tue, 2024-08-06 at 15:51 +0000, Claudio Siqueira de Carvalho wrote:
> > On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > > > [...]
> > > > > >
> > > > > > 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
> 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. 

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.
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. 

Best Regards,
Elena.

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

[James Bottomley]

On Wed, 2024-08-07 at 11:28 +0000, Reshetova, Elena wrote:
> > On Tue, 2024-08-06 at 15:51 +0000, Claudio Siqueira de Carvalho
> > wrote:
> > > On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze
> > > > > > > wrote:
> > > > > [...]
> > > > > > > 
> > > > > > > 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
> > 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.

> 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.

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.

> 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).

James

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

[Reshetova, Elena]

> On Wed, 2024-08-07 at 11:28 +0000, Reshetova, Elena wrote:
> > > On Tue, 2024-08-06 at 15:51 +0000, Claudio Siqueira de Carvalho
> > > wrote:
> > > > On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > > > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze
> > > > > > > > wrote:
> > > > > > [...]
> > > > > > > >
> > > > > > > > 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
> > > 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.
> 
> > 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. 

> 
> 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. 

> 
> > 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.
> 
> James

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

[Yao, Jiewen]

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 <cclaudio@ibm.com>; dionnaglaze@google.com
> Cc: jejb@linux.ibm.com; jroedel@suse.com; Nakajima, Jun
> <jun.nakajima@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>;
> jpiotrowski@linux.microsoft.com; Dong, Eddie <eddie.dong@intel.com>; Perez,
> Ronald <ronald.perez@intel.com>; Lange, Jon <jlange@microsoft.com>; linux-
> coco@lists.linux.dev; Johnson, Simon P <simon.p.johnson@intel.com>
> Subject: RE: Coconut-SVSM - vTPM support for Intel TD Partitioning
> 
> > On Wed, 2024-08-07 at 11:28 +0000, Reshetova, Elena wrote:
> > > > On Tue, 2024-08-06 at 15:51 +0000, Claudio Siqueira de Carvalho
> > > > wrote:
> > > > > On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > > > > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze
> > > > > > > > > wrote:
> > > > > > > [...]
> > > > > > > > >
> > > > > > > > > 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
> > > > 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.
> >
> > > 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.
> 
> >
> > 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.
> 
> >
> > > 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.
> >
> > James

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

[Dionna Amalie Glaze]

On Thu, Aug 15, 2024 at 8:38 PM Yao, Jiewen <jiewen.yao@intel.com> wrote:
>
> 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?
>
>

The design is ongoing in the early attestation document [1]. I
honestly don't think it can fully protect mutable NVS without
significant TCB increase since avoiding monotonic counter duplication
and rollback is hard. We can certainly persist an EK and SRK on first
boot and provision a sealing key for the NVS that's released with
early attestation, but that buys you... literally nothing? over the
evTPM solution of instead releasing the persistent SRK to the evTPM on
boot with early attestation. The EK would mean a "persistent
identity", but the way that you name the key to release is still going
to be a platform-controlled aspect. You can't avoid it. So just allow
your platform to sign an ephemeral EKpub cert with x509 extensions
that include platform identity information. That's more valuable,
since then you have a persistent identity that is backed by a
platform-held secret.

The EKpub cert is expected to be "signed" by the hardware attestation
to tie it back to the TEE, so I'm not sure even persisting the EK is
good from a security perspective since the certificate would have a
really old quote with no way to challenge it again. It might not be
best practice to make an ephemeral EKpub cert unchallengable, but at
least we can't find a flaw in it.

All this said, I think early attestation releasing some kind of key to
get access to some encrypted persisted blob is a common need between
evTPM full disk encryption support and persistent vTPM. We can execute
towards a standard pstore virtual device (virtio-blk?) to import a
sealed blob, and a standard network proxy device (virtio-vsock?) to
import a wrapped SRK from a key management service that has an
attestation verification policy protecting release.

[1] https://docs.google.com/document/d/11ZsxP8jsviP3ddp9Hrn0rf6inttNw_Pbnz0psXlxlPs/edit#heading=h.7jvpsq5illyd

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

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

[Yao, Jiewen]

Thanks for the sharing Dionna.

I am reading the early attestation doc and trying to put some comment there.

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Dionna Amalie Glaze <dionnaglaze@google.com>
> Sent: Saturday, August 17, 2024 12:14 AM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Reshetova, Elena <elena.reshetova@intel.com>; James Bottomley
> <James.Bottomley@hansenpartnership.com>; Claudio Siqueira de Carvalho
> <cclaudio@ibm.com>; jejb@linux.ibm.com; jroedel@suse.com; Nakajima, Jun
> <jun.nakajima@intel.com>; jpiotrowski@linux.microsoft.com; Dong, Eddie
> <eddie.dong@intel.com>; Perez, Ronald <ronald.perez@intel.com>; Lange, Jon
> <jlange@microsoft.com>; linux-coco@lists.linux.dev; Johnson, Simon P
> <simon.p.johnson@intel.com>
> Subject: Re: Coconut-SVSM - vTPM support for Intel TD Partitioning
> 
> On Thu, Aug 15, 2024 at 8:38 PM Yao, Jiewen <jiewen.yao@intel.com> wrote:
> >
> > 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?
> >
> >
> 
> The design is ongoing in the early attestation document [1]. I
> honestly don't think it can fully protect mutable NVS without
> significant TCB increase since avoiding monotonic counter duplication
> and rollback is hard. We can certainly persist an EK and SRK on first
> boot and provision a sealing key for the NVS that's released with
> early attestation, but that buys you... literally nothing? over the
> evTPM solution of instead releasing the persistent SRK to the evTPM on
> boot with early attestation. The EK would mean a "persistent
> identity", but the way that you name the key to release is still going
> to be a platform-controlled aspect. You can't avoid it. So just allow
> your platform to sign an ephemeral EKpub cert with x509 extensions
> that include platform identity information. That's more valuable,
> since then you have a persistent identity that is backed by a
> platform-held secret.
> 
> The EKpub cert is expected to be "signed" by the hardware attestation
> to tie it back to the TEE, so I'm not sure even persisting the EK is
> good from a security perspective since the certificate would have a
> really old quote with no way to challenge it again. It might not be
> best practice to make an ephemeral EKpub cert unchallengable, but at
> least we can't find a flaw in it.
> 
> All this said, I think early attestation releasing some kind of key to
> get access to some encrypted persisted blob is a common need between
> evTPM full disk encryption support and persistent vTPM. We can execute
> towards a standard pstore virtual device (virtio-blk?) to import a
> sealed blob, and a standard network proxy device (virtio-vsock?) to
> import a wrapped SRK from a key management service that has an
> attestation verification policy protecting release.
> 
> [1]
> https://docs.google.com/document/d/11ZsxP8jsviP3ddp9Hrn0rf6inttNw_Pbnz0ps
> XlxlPs/edit#heading=h.7jvpsq5illyd
> 
> --
> -Dionna Glaze, PhD, CISSP, CCSP (she/her)

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

[James Bottomley]

On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > [...]
> > > > 
> > > > 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.

You want the SVSM vTPM service for its tight binding to the guest VM, I
believe ... and you want to add a CRB emulation to the SVSM that
currently doesn't exist.

>  I assume you've done the same for other SVSM provided services like
> > deposit/remove memory and vcpu create/delete, but what about
> > migration when it comes along? 
> 
> Could you please give an example of where let's say we are not ok
> with existing Linux ways of depositing/removing memory?

OK, I looked but couldn't find it: how do you current add and remove
memory from the SVSM if you don't communicate with it?

>  Why do we need to create a new protocol like SVSM from guest kernel
> for doing this? It can be done if there is a valid usecase of course.
> All I am saying is that we haven’t found any yet.

Even in your model the SVSM performs services on behalf of the guest. I
think you mostly use traps and emulation instead of communication along
enlightened interfaces to get the SVSM to perform the services but one
of the historical lessons of virtualization has been that paravirt
enlightenments are useful in places (most particularly drivers).

Regards,

James


>  Since the high level operations will be pretty
> > much identical on AMD and Intel it would be very annoying to have
> > to do it in completely different ways (with presumably different
> > tools).
> 
> Migration is a separate story, which i dont think has any conclusion
> yet or agreement in the community. We (Intel TDX) have a way to
> migrate the guest without the guest assistance, so we dont have a
> strict requirement to migrate out of SVSM. It remains to be seen what
> method(s) is to be selected at the end. And if svsm-based migration
> method is going to be supported for intel tdx, then it needs a
> separate analysis to determine what is the actual required
> communication between the L2 guest and SVSM in our case and whenever
> the usage of the SVSM-style protocol is necessary.  
> 
> Imo migration is one of the topics that would be great to discuss at
> LPC.
> 
> Best Regards,
> Elena. 
> 
> > 
> > Regards,
> > 
> > James
> 

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

[Reshetova, Elena]

> On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > > [...]
> > > > >
> > > > > 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.
> 
> You want the SVSM vTPM service for its tight binding to the guest VM, I
> believe ... and you want to add a CRB emulation to the SVSM that
> currently doesn't exist.
> 

I will leave it to Jiewen to comment on the vTPM case, he is more 
knowledgeable on the details here. 

> >  I assume you've done the same for other SVSM provided services like
> > > deposit/remove memory and vcpu create/delete, but what about
> > > migration when it comes along?
> >
> > Could you please give an example of where let's say we are not ok
> > with existing Linux ways of depositing/removing memory?
> 
> OK, I looked but couldn't find it: how do you current add and remove
> memory from the SVSM if you don't communicate with it?

I think we would need to define the usecase precisely first to avoid
confusion. I guess you are talking about VM guest (L2 guest in
TDX terminology) OS possibility to add/remove memory in runtime, 
aka memory hotplug, correct? We have started to look into this
recently and Linux supports this capability via different paths,
including ACPI hotplug and virtio-mem. So, the goal to enable mem
hotplug would be to make sure that relevant code paths are
working for both 1) normal TDX Linux guest (running in L1 with
no SVSM) as well for L2 guest running under SVSM,
ideally using the same code in Linux guest. And this is where our
difference in architecture comes from: we can
use the same code in both L1 and L2 to do this, instead of having
the code of style: 

if (running in L1)
   do foo;
else
   do bar;

So we can issue a single paravirt call from both L1 and L2 to do required
things, i.e. memory acceptance (TDG.MEM.PAGE.ACCEPT in TDX terms), etc.
In case the call is issued by L2 (as any TDG.*call by L2), it will generate by
default (this can be configured by L1) an L2 -> L1 exit (host/L0 is not involved,
exit is pretty cheap since we stay in secure context), L1 can inspect the args
and decide to emulate/drop/reject/do whatever it needs with this. 


> 
> >  Why do we need to create a new protocol like SVSM from guest kernel
> > for doing this? It can be done if there is a valid usecase of course.
> > All I am saying is that we haven’t found any yet.
> 
> Even in your model the SVSM performs services on behalf of the guest. I
> think you mostly use traps and emulation instead of communication along
> enlightened interfaces to get the SVSM to perform the services but one
> of the historical lessons of virtualization has been that paravirt
> enlightenments are useful in places (most particularly drivers).

Yes, paravirt englightments are important and no one challenges this fact.
When we run Linux as normal TDX guest (without SVSM) it is already
enlightened and using our TDG.* paravirt interface to do many things.
The core idea here is to use the *same* paravirt interface also when running in
L2 under SVSM vs. doing one more enligthment for L2 case *specifically*.
And again, I repeat, if we see usecases that require this L2 specific engligthment,
then this approach can be reconsidered. At that moment we will have 
smth concrete to go to x86 maintainers and say that we have a valid reason
to start adding additional complexity into our tdx or core x86 specific code.
We dont have any concrete usecases to justify this complexity at the moment
on TDX.

All the above is of course only given the fact that we want to support both:
Linux running in L1 (with no SVSM) and Linux in L2 with SVSM. It is an interesting
discussion question for the community what setup (or both) makes sense in the long run.
So far, we are making sure we support both.

Best Regards,
Elena.

> 
> Regards,
> 
> James
> 
> 
> >  Since the high level operations will be pretty
> > > much identical on AMD and Intel it would be very annoying to have
> > > to do it in completely different ways (with presumably different
> > > tools).
> >
> > Migration is a separate story, which i dont think has any conclusion
> > yet or agreement in the community. We (Intel TDX) have a way to
> > migrate the guest without the guest assistance, so we dont have a
> > strict requirement to migrate out of SVSM. It remains to be seen what
> > method(s) is to be selected at the end. And if svsm-based migration
> > method is going to be supported for intel tdx, then it needs a
> > separate analysis to determine what is the actual required
> > communication between the L2 guest and SVSM in our case and whenever
> > the usage of the SVSM-style protocol is necessary.
> >
> > Imo migration is one of the topics that would be great to discuss at
> > LPC.
> >
> > Best Regards,
> > Elena.
> >
> > >
> > > Regards,
> > >
> > > James
> >
> 

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

[Yao, Jiewen]

Hi
I am back from vocation and trying to answer rest of questions.

For CRB emulation, right, it is not present today.
We added https://github.com/intel-staging/td-partitioning-svsm/blob/svsm-tdp-vtpm/kernel/src/vtpm/ptp/crb.rs.

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Reshetova, Elena <elena.reshetova@intel.com>
> Sent: Wednesday, August 7, 2024 4:47 PM
> To: James Bottomley <James.Bottomley@HansenPartnership.com>; Dionna
> Amalie Glaze <dionnaglaze@google.com>
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; jejb@linux.ibm.com; Jeremi Piotrowski
> <jpiotrowski@linux.microsoft.com>; Claudio Siqueira de Carvalho
> <cclaudio@ibm.com>; Rödel, Jörg <jroedel@suse.com>; Lange, Jon
> <jlange@microsoft.com>; Dong, Eddie <eddie.dong@intel.com>; Johnson, Simon
> P <simon.p.johnson@intel.com>; Nakajima, Jun <jun.nakajima@intel.com>;
> Perez, Ronald <ronald.perez@intel.com>; linux-coco@lists.linux.dev
> Subject: RE: Coconut-SVSM - vTPM support for Intel TD Partitioning
> 
> > On Tue, 2024-08-06 at 08:21 +0000, Reshetova, Elena wrote:
> > > > On Mon, 2024-08-05 at 09:55 +0000, Reshetova, Elena wrote:
> > > > > > On Fri, 2024-08-02 at 18:54 -0700, Dionna Amalie Glaze wrote:
> > > > [...]
> > > > > >
> > > > > > 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.
> >
> > You want the SVSM vTPM service for its tight binding to the guest VM, I
> > believe ... and you want to add a CRB emulation to the SVSM that
> > currently doesn't exist.
> >
> 
> I will leave it to Jiewen to comment on the vTPM case, he is more
> knowledgeable on the details here.
> 
> > >  I assume you've done the same for other SVSM provided services like
> > > > deposit/remove memory and vcpu create/delete, but what about
> > > > migration when it comes along?
> > >
> > > Could you please give an example of where let's say we are not ok
> > > with existing Linux ways of depositing/removing memory?
> >
> > OK, I looked but couldn't find it: how do you current add and remove
> > memory from the SVSM if you don't communicate with it?
> 
> I think we would need to define the usecase precisely first to avoid
> confusion. I guess you are talking about VM guest (L2 guest in
> TDX terminology) OS possibility to add/remove memory in runtime,
> aka memory hotplug, correct? We have started to look into this
> recently and Linux supports this capability via different paths,
> including ACPI hotplug and virtio-mem. So, the goal to enable mem
> hotplug would be to make sure that relevant code paths are
> working for both 1) normal TDX Linux guest (running in L1 with
> no SVSM) as well for L2 guest running under SVSM,
> ideally using the same code in Linux guest. And this is where our
> difference in architecture comes from: we can
> use the same code in both L1 and L2 to do this, instead of having
> the code of style:
> 
> if (running in L1)
>    do foo;
> else
>    do bar;
> 
> So we can issue a single paravirt call from both L1 and L2 to do required
> things, i.e. memory acceptance (TDG.MEM.PAGE.ACCEPT in TDX terms), etc.
> In case the call is issued by L2 (as any TDG.*call by L2), it will generate by
> default (this can be configured by L1) an L2 -> L1 exit (host/L0 is not involved,
> exit is pretty cheap since we stay in secure context), L1 can inspect the args
> and decide to emulate/drop/reject/do whatever it needs with this.
> 
> 
> >
> > >  Why do we need to create a new protocol like SVSM from guest kernel
> > > for doing this? It can be done if there is a valid usecase of course.
> > > All I am saying is that we haven't found any yet.
> >
> > Even in your model the SVSM performs services on behalf of the guest. I
> > think you mostly use traps and emulation instead of communication along
> > enlightened interfaces to get the SVSM to perform the services but one
> > of the historical lessons of virtualization has been that paravirt
> > enlightenments are useful in places (most particularly drivers).
> 
> Yes, paravirt englightments are important and no one challenges this fact.
> When we run Linux as normal TDX guest (without SVSM) it is already
> enlightened and using our TDG.* paravirt interface to do many things.
> The core idea here is to use the *same* paravirt interface also when running in
> L2 under SVSM vs. doing one more enligthment for L2 case *specifically*.
> And again, I repeat, if we see usecases that require this L2 specific engligthment,
> then this approach can be reconsidered. At that moment we will have
> smth concrete to go to x86 maintainers and say that we have a valid reason
> to start adding additional complexity into our tdx or core x86 specific code.
> We dont have any concrete usecases to justify this complexity at the moment
> on TDX.
> 
> All the above is of course only given the fact that we want to support both:
> Linux running in L1 (with no SVSM) and Linux in L2 with SVSM. It is an interesting
> discussion question for the community what setup (or both) makes sense in the
> long run.
> So far, we are making sure we support both.
> 
> Best Regards,
> Elena.
> 
> >
> > Regards,
> >
> > James
> >
> >
> > >  Since the high level operations will be pretty
> > > > much identical on AMD and Intel it would be very annoying to have
> > > > to do it in completely different ways (with presumably different
> > > > tools).
> > >
> > > Migration is a separate story, which i dont think has any conclusion
> > > yet or agreement in the community. We (Intel TDX) have a way to
> > > migrate the guest without the guest assistance, so we dont have a
> > > strict requirement to migrate out of SVSM. It remains to be seen what
> > > method(s) is to be selected at the end. And if svsm-based migration
> > > method is going to be supported for intel tdx, then it needs a
> > > separate analysis to determine what is the actual required
> > > communication between the L2 guest and SVSM in our case and whenever
> > > the usage of the SVSM-style protocol is necessary.
> > >
> > > Imo migration is one of the topics that would be great to discuss at
> > > LPC.
> > >
> > > Best Regards,
> > > Elena.
> > >
> > > >
> > > > Regards,
> > > >
> > > > James
> > >
> >

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

[Yao, Jiewen]

Thank you very much to let us know.

Currently, we are trying to reuse what coconut-svsm does as much as possible, and only change when it is necessary.

I agree that this should be done before final production phase.
I filed an issue https://github.com/coconut-svsm/svsm/issues/440, to track this migration task.


Thank you
Yao, Jiewen

> -----Original Message-----
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Sent: Friday, August 2, 2024 11:40 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>; jejb@linux.ibm.com; Jeremi Piotrowski
> <jpiotrowski@linux.microsoft.com>; Claudio Siqueira de Carvalho
> <cclaudio@ibm.com>; Rödel, Jörg <jroedel@suse.com>
> Cc: Lange, Jon <jlange@microsoft.com>; Dong, Eddie <eddie.dong@intel.com>;
> Johnson, Simon P <simon.p.johnson@intel.com>; Reshetova, Elena
> <elena.reshetova@intel.com>; Nakajima, Jun <jun.nakajima@intel.com>; Perez,
> Ronald <ronald.perez@intel.com>; linux-coco@lists.linux.dev
> Subject: Re: Coconut-SVSM - vTPM support for Intel TD Partitioning
> 
> On Thu, 2024-08-01 at 22:38 +0000, Yao, Jiewen wrote:
> > 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
> > .
> 
> Just a note for the vTPM reference implementation which, I think,
> applies to both you and the current SVSM-vTPM: the reference TPM
> implementation has moved to
> 
> https://github.com/TrustedComputingGroup/TPM
> 
> And the one you list (https://github.com/microsoft/ms-tpm-20-ref) is
> now a stale copy that isn't being kept up to date.
> 
> Regards,
> 
> James

Re: question on vTPM interface in coconut-svsm

[Joerg Roedel]

Hi Jiewen,

First of all: I it really great that Intel plans to use and contribute to COCONUT-SVSM! For your questions, let me add some general statements here about how COCONUT plans to handle device interfaces in the future.

> Am 28.03.2024 um 07:29 schrieb Yao, Jiewen <jiewen.yao@intel.com>:
> 
> Questions:
> With this POC, it seems TCG CRB interface [7] is a feasible option for vTPM in coconut-svsm. We are NOT clear what is the motivation to have a new vTPM protocol [4].
> Would you please educate us on that? Why not reuse TCG CRB interface [7], but introduce a new one [4]?

The current vTPM code in COCONUT-SVSM implements an SVSM specific communication mechanism between the guest OS and the SVSM. The main reason behind this is that the implementation for AMD SEV-SNP targets an operation mode for running enlightened OSes. That means that the OS is aware of running in a CVM and also on-top of an SVSM. The OS still handles VC exceptions (equivalent of VE on TDX) itself, which makes it harder to emulate an MMIO-based device interface in the SVSM. Since the OS is already aware of the SVSM and because of the difficulties of implementing a CRB interface in this mode, the SVSM offers a communication protocol to the OS for using the TPM emulation.

In the future the SVSM will also support the paravisor mode, where it handles VC/VE exceptions on behalf of the guest OS. In this mode the SVSM will emulate MMIO and it makes more sense to offer a TPM interface via CRB because the guest OS might not be aware of running in a CVM and/or on-top of a paravisor.

So if Intel wants to support paravisor mode for TDX first and add enlightened OS support later, it is totally fine to implement a CRB interface in front of the existing TPM implementation in addition to the existing SVSM protocol interface.

In general this is true for all device emulations the SVSM will provide in the future. In enlightened OS mode it is easier and more performant to define SVSM-specific protocols and in paravisor mode the SVSM can implement the interface of the real hardware device it is emulating.

Hope that clarifies a few things, let me know if you have further questions.

Regards,

Jörg

RE: question on vTPM interface in coconut-svsm

[Yao, Jiewen]

Thank you very much Joerg. That explains a lot.

Yes, I am in the internal process of posting CRB based vTPM solution in coconut-SVSM. Once the internal process is complete, we will submit the CRB patch.

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Joerg Roedel <jroedel@suse.com>
> Sent: Monday, April 8, 2024 4:51 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: linux-coco@lists.linux.dev; James Bottomley <jejb@linux.ibm.com>; Claudio
> Siqueira de Carvalho <cclaudio@ibm.com>; Lange, Jon <jlange@microsoft.com>;
> Dong, Eddie <eddie.dong@intel.com>; Johnson, Simon P
> <simon.p.johnson@intel.com>; Reshetova, Elena <elena.reshetova@intel.com>;
> Nakajima, Jun <jun.nakajima@intel.com>
> Subject: Re: question on vTPM interface in coconut-svsm
> 
> Hi Jiewen,
> 
> First of all: I it really great that Intel plans to use and contribute to COCONUT-
> SVSM! For your questions, let me add some general statements here about how
> COCONUT plans to handle device interfaces in the future.
> 
> > Am 28.03.2024 um 07:29 schrieb Yao, Jiewen <jiewen.yao@intel.com>:
> >
> > Questions:
> > With this POC, it seems TCG CRB interface [7] is a feasible option for vTPM in
> coconut-svsm. We are NOT clear what is the motivation to have a new vTPM
> protocol [4].
> > Would you please educate us on that? Why not reuse TCG CRB interface [7], but
> introduce a new one [4]?
> 
> The current vTPM code in COCONUT-SVSM implements an SVSM specific
> communication mechanism between the guest OS and the SVSM. The main
> reason behind this is that the implementation for AMD SEV-SNP targets an
> operation mode for running enlightened OSes. That means that the OS is aware of
> running in a CVM and also on-top of an SVSM. The OS still handles VC exceptions
> (equivalent of VE on TDX) itself, which makes it harder to emulate an MMIO-
> based device interface in the SVSM. Since the OS is already aware of the SVSM
> and because of the difficulties of implementing a CRB interface in this mode, the
> SVSM offers a communication protocol to the OS for using the TPM emulation.
> 
> In the future the SVSM will also support the paravisor mode, where it handles
> VC/VE exceptions on behalf of the guest OS. In this mode the SVSM will emulate
> MMIO and it makes more sense to offer a TPM interface via CRB because the
> guest OS might not be aware of running in a CVM and/or on-top of a paravisor.
> 
> So if Intel wants to support paravisor mode for TDX first and add enlightened OS
> support later, it is totally fine to implement a CRB interface in front of the existing
> TPM implementation in addition to the existing SVSM protocol interface.
> 
> In general this is true for all device emulations the SVSM will provide in the future.
> In enlightened OS mode it is easier and more performant to define SVSM-specific
> protocols and in paravisor mode the SVSM can implement the interface of the real
> hardware device it is emulating.
> 
> Hope that clarifies a few things, let me know if you have further questions.
> 
> Regards,
> 
> Jörg