linux-kernel - Re: [PATCH v6 4/4] x86/sev: register tpm-svsm 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: <409a9171bc3224dd55344729ab3106917ac113bf.camel@HansenPartnership.com>
Date: Wed, 09 Apr 2025 08:22:37 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Borislav Petkov <bp@...en8.de>, Stefano Garzarella <sgarzare@...hat.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Peter Huewe <peterhuewe@....de>, Jason
 Gunthorpe <jgg@...pe.ca>, "H. Peter Anvin" <hpa@...or.com>,
 linux-coco@...ts.linux.dev,  linux-integrity@...r.kernel.org, Ingo Molnar
 <mingo@...hat.com>, x86@...nel.org,  Tom Lendacky
 <thomas.lendacky@....com>, Joerg Roedel <jroedel@...e.de>, Dionna Glaze
 <dionnaglaze@...gle.com>,  Claudio Carvalho <cclaudio@...ux.ibm.com>,
 linux-kernel@...r.kernel.org, Dov Murik <dovmurik@...ux.ibm.com>,  Thomas
 Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v6 4/4] x86/sev: register tpm-svsm platform device

On Wed, 2025-04-09 at 13:31 +0200, Borislav Petkov wrote:
> On Wed, Apr 09, 2025 at 12:43:01PM +0200, Stefano Garzarella wrote:
> > Sorry, maybe I missed something.
> > 
> > tpm_svsm.c registers the driver with
> > module_platform_driver_probe().
> > 
> > Someone (the platform I guess) has to register the device by
> > calling platform_device_register(), as we already do for example
> > for sev_guest.
> 
> Maybe that platform device thing is the wrong approach. Why does the
> core code need to register some dummy platform device in the first
> place? Why can't drivers/char/tpm/tpm_svsm.c probe and init without
> it?

Because of the way driver and device matching works in Linux.  We have
to have a struct device because that sits at the he heart of the TPM
driver binding.  If we have a struct device, it has to sit on a bus
(because that's the Linux design) and if we don't have a bus then we
have to use a platform device (or, now, we could use a struct device on
the faux bus).  Busses can be either physical (PCI, GSC, ...) and
abstract (virtio, xen, scsi, ...), so it's not impossible, if the SVSM
has more than one device, that it should have it's own SVSM bus which
we could then act a bit like the virtio bus and the SVSM vTPM struct
device could sit on this (the TPM subsystem, like most driver
subsystems, doesn't care about busses, it only cares that the abstract
bus device id matching works).

Regards,

James