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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D725V628UV87.31SUEYVF9IUUC@kernel.org>
Date: Wed, 15 Jan 2025 00:48:46 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jarkko Sakkinen" <jarkko@...nel.org>, "Stefano Garzarella"
 <sgarzare@...hat.com>, "Jarkko Sakkinen" <jarkko.sakkinen@....fi>
Cc: "Jason Gunthorpe" <jgg@...pe.ca>, "James Bottomley"
 <james.bottomley@...senpartnership.com>, <linux-coco@...ts.linux.dev>,
 "Borislav Petkov" <bp@...en8.de>, "Dave Hansen"
 <dave.hansen@...ux.intel.com>, "Peter Huewe" <peterhuewe@....de>, "H. Peter
 Anvin" <hpa@...or.com>, <linux-integrity@...r.kernel.org>,
 <x86@...nel.org>, "Joerg Roedel" <jroedel@...e.de>,
 <linux-kernel@...r.kernel.org>, "Ingo Molnar" <mingo@...hat.com>, "Thomas
 Gleixner" <tglx@...utronix.de>, "Claudio Carvalho"
 <cclaudio@...ux.ibm.com>, "Dov Murik" <dovmurik@...ux.ibm.com>, "Tom
 Lendacky" <thomas.lendacky@....com>
Subject: Re: [PATCH 3/3] x86/sev: add a SVSM vTPM platform device

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@...hat.com> 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.

BR, Jarkko