Re: Secure vTPMs for confidential VMs

[Tom Lendacky <thomas.lendacky@amd.com>]

On 9/21/22 03:49, Jörg Rödel wrote:
> Hi Dov,
> 
> On Tue, Sep 20, 2022 at 11:28:15PM +0300, Dov Murik wrote:
>> * Implementation in TEEs: SNP introduced VPMLs, and AMD's linux-SVSM
>> running in VPML0 can also run vTPM code to handle TPM requests from the
>> guest running in VMPL1.  Such a solution is not applicable as-is to
>> other TEEs (SEV, TDX).  People suggested running vTPMs in a separate
>> confidential VMs, and somehow connect the tenant's guest to the TPM VM;
>> but we'll need a way to secure this communication channel.
> 
> Yes, so for SEV-SNP the way to implement a vTPM is via a Secure VM
> Service Module (SVSM) running at VMPL0.
> 
> I not sure how much we should care about the variant of running a vTPM
> in a separate trusted VM. In the long run SEV and SEV-ES will be
> replaced by SEV-SNP, and for TDX it would be best if Intel just adds a
> software TPM into their SEAM module. IIRC TDX already has some TPM-like
> features, e.g. PCRs, implemented there. A full vTPM seems to be doable.
> 
>> * Guest enlightment: Guest software currently interacts with the TPM by
>> writing commands to a memory-mapped IO page (GPA 0xfed40000) and reading
>> responses from that page.  We want such writes to trigger the code of
>> our vTPM (for whatever implementation we choose).  Our current early
>> experience with TPM running in linux-SVSM required adding "exit-guest"
>> calls after writing commands to the IO page, in order to allow the SVSM
>> to run and recognize the incoming command.  Ideally, we'd like a
>> solution that doesn't require modifying all the TPM drivers out there
>> (in Linux, Windows, OVMF, grub, ...).
> 
> It will not be that easy to emulate a vTPM at VMPL0 which has the same
> interface as memory mapped TPMs. That would mean marking the page as
> MMIO, but that will trigger a VC exception in the OS (or OVMF, Grub,
> ...), which would then need to forward the MMIO access to the SVSM. So
> either way, OVMF and Grub need modification to work with a vTPM running
> at a lower VMPL.

Agreed.

> 
> An alternative is using the ReflectVC feature to get the VC directed to
> the lower VMPL, but that has much wider implications and is not
> justified for only emulating a vTPM.

Using ReflectVC is geared more towards supporting un-enligtened guests. We 
don't want the SVSM to have to handle all #VCs that are triggered in the 
guest.

> 
> The current plan is to have VMPL1 talk to the VMPL0 vTPM via
> standardised SVSM commands. This requires new TPM drivers for all VMPL1
> components. At least unless someone comes up with a better idea :)

This is probably the best approach. We will have to modify the kernel no 
matter what, either recognize the MMIO range being accessed from within 
the #VC handler (and then parse the instruction, etc.) or modify/create a 
TPM driver that talks to the SVSM (and thus eliminates the exception 
path). Either way, an update to the kernel is required.

I'm not an expert in TPMs, but when using an SVSM enligntened TPM driver, 
maybe it becomes possible to even batch up multiple operations, which 
would improve overall performance.

We need to start looking at what the interface to the SVSM would look 
like. What is required from the SVSM (e.g. attestation report) and how to 
provide that to the VMPL1 guest, what is required to be supplied by the 
VMPL1 guest to perform the operation, etc.

To that end we can probably start talking about how we want to advertise 
support for a vTPM in the SVSM. I imagine it will be a new protocol with 
new functions (btw, look for an announcement shortly as the SVSM draft 
specification is now available from our website).

Thanks,
Tom

> 
> Regards,
>