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

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