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] [day] [month] [year] [list]

Message-ID: <CAAH4kHYy7=OZsHnOBiQug0Y__bNHt6i+bop0xaxQjpWQ6aQr1Q@mail.gmail.com>
Date: Wed, 22 Jan 2025 13:29:42 -0800
From: Dionna Amalie Glaze <dionnaglaze@...gle.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Stefano Garzarella <sgarzare@...hat.com>, Jarkko Sakkinen <jarkko.sakkinen@....fi>, 
	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 Tue, Jan 14, 2025 at 3:12 PM Jarkko Sakkinen <jarkko@...nel.org> wrote:
>
> 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@...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.
>
> 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).

I can appreciate this viewpoint. It even surfaced Microsoft's fTPM
paper to me, which solves some interesting problems we need to solve
in SVSM too. So thanks for that.

Just to clarify, you're not asking for SVSM to implement the TIS-MMIO
interface instead, but rather to use the fTPM stack, which could make
SVSM calls a TEE device operation?

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


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)