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: <50a2e1d29b065498146f459035e447851a518d1a.camel@HansenPartnership.com>
Date: Tue, 10 Dec 2024 09:55:41 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jason Gunthorpe <jgg@...pe.ca>, Stefano Garzarella <sgarzare@...hat.com>
Cc: 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>, Jarkko Sakkinen <jarkko@...nel.org>, 
 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, 2024-12-10 at 10:40 -0400, Jason Gunthorpe wrote:
> On Tue, Dec 10, 2024 at 03:34:23PM +0100, Stefano Garzarella wrote:
> 
> > +               if (platform_device_add_data(&tpm_device, &pops,
> > sizeof(pops)))
> > +                       return -ENODEV;
> > +               if (platform_device_register(&tpm_device))
> > +                       return -ENODEV;
> 
> This seems like an old fashioned way to instantiate a device. Why do
> this? Just put the TPM driver here and forget about pops? Simple tpm
> drivers are not very complex.

This driver may be for the AMD SEV SVSM vTPM module, but there are
other platforms where there's an internal vTPM which might be contacted
via a platform specific enlightenment (Intel SNP and Microsoft
OpenHCL).  This separation of the platform device from the contact
mechanism is designed to eliminate the duplication of having a platform
device within each implementation and to make any bugs in the mssim
protocol centrally fixable (every vTPM currently speaks this).

Regards,

James