Re: Secure vTPMs for confidential VMs

["Jörg Rödel" <jroedel@suse.de>]

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.

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.

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

Regards,

-- 
Jörg Rödel
jroedel@suse.de

SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman