Re: [PATCH 3/3] x86/sev: add a SVSM vTPM platform device

[Jarkko Sakkinen]

On Tue Jan 14, 2025 at 12:42 PM EET, Stefano Garzarella wrote:
> Hi Jarkko,
>
> On Thu, 19 Dec 2024 at 17:07, Stefano Garzarella <sgarzare@xxxxxxxxxx> wrote:
> >
> > On Thu, Dec 19, 2024 at 05:40:58PM +0200, Jarkko Sakkinen wrote:
> > >On Thu Dec 19, 2024 at 5:35 PM EET, Stefano Garzarella wrote:
> > >> So to use them directly in sev, we would have to move these definitions
> > >> into include/linux/tpm.h or some other file in inlcude/. Is this
> > >> acceptable for TPM maintainers?
> > >
> > >There's only me.
> > >
> > >I don't know.
> > >
> > >What you want to put to include/linux/tpm.h anyway?
> >
> > At least tpmm_chip_alloc(), tpm2_probe(), and tpm_chip_register()
> >
> > >I have not followed this discussion.
> >
> > Let me try to summarize what we are doing: We are writing a small TPM
> > driver to support AMD SEV-SNP SVSM. Basically SVSM defines some sort of
> > hypercalls, which the guest OS can call to talk to the emulated vTPM.
> >
> > In the current version of this series, based on James' RFC, we have an
> > intermediate module (tpm_platform) and then another small driver
> > (platform_device) in arch/x86/coco/sev/core.c that registers the
> > callback to use.
> >
> > To avoid the intermediate driver (Jason correct me if I misunderstood),
> > we want to register the `tpm_chip` with its `tpm_class_ops` directly in
> > arch/x86/coco/sev/core.c where it's easy to use "SVSM calls" (i.e.
> > svsm_perform_call_protocol()).
> >
> > And here I have this problem, so I was proposing to expose these APIs.
> > BTW, we do have an alternative though that I proposed in the previous
> > email that might avoid this.
>
> Any thought on this?

A redundant super low-quality TPM stack driver implemtation to support
only single vendor's vTPM with speculative generalization.

It's a formula for destruction really.

I don't know if I event want to comment on this. Figure out a better
solution I guess that works together sound with existing stack.

If that helps we could make the main TPM driver only Y/N (instead of
tristate).

>
> Thanks,
> Stefano

[1] "could be used by any platform which communicates with a TPM device."

BR, Jarkko