Re: question on vTPM interface in coconut-svsm

[Joerg Roedel <jroedel@suse.com>]

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.