Re: question on vTPM interface in coconut-svsm

[Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>]

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