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

On Mon, Mar 17, 2025 at 03:34:10PM +0200, Jarkko Sakkinen wrote:
>On Fri, Mar 14, 2025 at 11:56:31AM -0500, Tom Lendacky wrote:
>> On 3/11/25 04:42, Stefano Garzarella wrote:
>> > SNP platform can provide a vTPM device emulated by SVSM.
>> >
>> > The "tpm-svsm" device can be handled by the platform driver added
>> > by the previous commit in drivers/char/tpm/tpm_svsm.c
>> >
>> > The driver will call snp_svsm_vtpm_probe() to check if SVSM is
>> > present and if it's support the vTPM protocol.
>> >
>> > Signed-off-by: Stefano Garzarella <sgarzare@...hat.com>
>> > ---
>> >  arch/x86/coco/sev/core.c | 8 ++++++++
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/arch/x86/coco/sev/core.c b/arch/x86/coco/sev/core.c
>> > index 2166bdff88b7..a2383457889e 100644
>> > --- a/arch/x86/coco/sev/core.c
>> > +++ b/arch/x86/coco/sev/core.c
>> > @@ -2664,6 +2664,11 @@ static struct platform_device sev_guest_device = {
>> >  	.id		= -1,
>> >  };
>> >
>> > +static struct platform_device tpm_svsm_device = {
>> > +	.name		= "tpm-svsm",
>> > +	.id		= -1,
>> > +};
>> > +
>> >  static int __init snp_init_platform_device(void)
>> >  {
>> >  	if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP))
>> > @@ -2672,6 +2677,9 @@ static int __init snp_init_platform_device(void)
>> >  	if (platform_device_register(&sev_guest_device))
>> >  		return -ENODEV;
>> >
>> > +	if (platform_device_register(&tpm_svsm_device))
>> > +		return -ENODEV;
>> > +
>>
>> You could avoid registering the device if an SVSM isn't present. Not sure
>> if that is desirable or not.
>
>Is there any use for the device if an SVSM isn't present? :-)
>
>I'd judge it based on that...

I tried to keep the logic of whether or not the driver is needed all in 
the tpm_svsm_probe()/snp_svsm_vtpm_probe() (where I check for SVSM).
If you prefer to move some pieces here, though, I'm open.

Thanks,
Stefano