On Wed Jan 15, 2025 at 12:48 AM EET, Jarkko Sakkinen wrote: > On Wed Jan 15, 2025 at 12:46 AM EET, Jarkko Sakkinen wrote: > > 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). > > Also e.g. James' hmac encryption: not a single bug fixed by the author, > which does further reduce my ability to have any possible trust on this. > > I do care quality over features, sorry. One more rant. It's engineering problem to find **a fit** for the existing art. For You can set the constraint here as "no two TPM stacks". I know also almost nothing about SVSM. E.g. I don't understand why a vTPM cannot be seen as fTPM by the guest, and why this needs user space exported device (please do not answer here, do a better job instead). Even if I wanted to say how this should be changed, I could not because it too far away to make any possible sense to begin with. And I don't want to take the risk of those words being used as an argument later on, when I don't even know what I'm looking. BR, Jarkko
