linux-kernel - Re: [RFC PATCH v2 3/6] tpm: add send_recv() ops in tpm_class

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: <Z8dg46Mj81Q9Z0WV@kernel.org>
Date: Tue, 4 Mar 2025 22:21:55 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Stefano Garzarella <sgarzare@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	Claudio Carvalho <cclaudio@...ux.ibm.com>,
	Peter Huewe <peterhuewe@....de>, x86@...nel.org,
	Dov Murik <dovmurik@...ux.ibm.com>, linux-coco@...ts.linux.dev,
	Dionna Glaze <dionnaglaze@...gle.com>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
	Jason Gunthorpe <jgg@...pe.ca>, linux-integrity@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	Borislav Petkov <bp@...en8.de>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [RFC PATCH v2 3/6] tpm: add send_recv() ops in tpm_class_ops

On Tue, Mar 04, 2025 at 06:56:02PM +0200, Jarkko Sakkinen wrote:
> On Mon, 2025-03-03 at 17:21 +0100, Stefano Garzarella wrote:
> > On Sat, Mar 01, 2025 at 03:45:10AM +0200, Jarkko Sakkinen wrote:
> > > On Fri, Feb 28, 2025 at 06:07:17PM +0100, Stefano Garzarella wrote:
> > > > +	int (*send_recv)(struct tpm_chip *chip, u8 *buf, size_t
> > > > buf_len,
> > > > +			 size_t to_send);
> > > 
> > > Please describe the meaning and purpose of to_send.
> > 
> > Sure, I'll add in the commit description.
> 
> It's always a command, right? So better be more concerete than
> "to_send", e.g. "cmd_len".
> 
> I'd do instead:
> 
> if (!chip->send)
> 	goto out_recv;
> 
> And change recv into:
> 
> int (*recv)(struct tpm_chip *chip, u8 *buf, size_t buf_len,
> 	    cmd_len);

I think I went here over the top, and *if* we need a new callback
putting send_recv would be fine. Only thing I'd take from this is to
rename to_len as cmd_len.

However, I don't think there are strong enough reasons to add complexity
to the callback interface with the basis of this single driver. You
should deal with this internally inside the driver instead.

So do something along the lines of, e.g.:

1. Create dummy send() copying the command to internal
   buffer.
2. Create ->status() returning zero, and set req_complete_mask and
   req_complete_val to zero.
3. Performan transaction in recv().

How you split send_recv() between send() and recv() is up to you. This
was merely showing that we don't need send_recv() desperately.

BR, Jarkko