Re: Secure vTPMs for confidential VMs

[Tobin Feldman-Fitzthum <tobin@linux.ibm.com>]

On 9/21/22 1:07 PM, Tom Lendacky wrote:
> On 9/21/22 03:49, Jörg Rödel wrote:
>>
>> 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.
> 
Yeah, supporting unenlightened guests is tricky. We were initially
thinking we could use the RMP table to cause an exit on the MMIO writes
and have the HV transfer control to VMPL0, but it's fairly complex (and
slow) to figure out what VMPL1 was about to write.

Still, it would be really big if we could do this without diverging from
the existing TPM interfaces. So here's a totally orthogonal idea that
you might not like.

What about adding an additional vCPU to the guest? This extra vCPU would
always run at VMPLO and would simply watch the TPM MMIO region. This
vCPU would also handle TPM emulation.

I realize this isn't really how AMD have envisioned using VMPL0
(although it could work alongside the current approach), but I think it
has some advantages. First, it seems like it would allow us to use the
existing interfaces without adding much extra complexity.

Second, I think it might be more in line with what we could support on
other platforms. Only SEV-SNP has VMPLs. It seems likely that any
complex reflection-based approach won't work on other platforms. Having
a vTPM VMPL0 vCPU on the other hand, would be fairly similar to having a
second VM with a shared address space. We might even be able to
implement something similar on SEV(-ES) using the so-called mirror VM.

Now there are also some drawbacks, but I'll let you guys point those out.

-Tobin
> 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,
>>