linux-kernel - Re: [PATCH 2/2] tpm/tpm_ftpm_tee: use send

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: <Z-QV5y1JGBDpsPuH@kernel.org>
Date: Wed, 26 Mar 2025 16:57:43 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Sumit Garg <sumit.garg@...nel.org>,
	Stefano Garzarella <sgarzare@...hat.com>,
	linux-kernel@...r.kernel.org, Peter Huewe <peterhuewe@....de>,
	linux-integrity@...r.kernel.org,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	Jens Wiklander <jens.wiklander@...aro.org>
Subject: Re: [PATCH 2/2] tpm/tpm_ftpm_tee: use send_recv() op

On Wed, Mar 26, 2025 at 11:34:01AM -0300, Jason Gunthorpe wrote:
> On Wed, Mar 26, 2025 at 02:11:12PM +0200, Jarkko Sakkinen wrote:
> 
> > Generally speaking I don't see enough value in complicating
> > callback interface. It's better to handle complications in
> > the leaves (i.e. dictatorship of majority ;-) ).
> 
> That is very much not the way most driver subsystems view the
> world. We want to pull logical things into the core code and remove
> them from drivers to make the drivers simpler and more robust.
> 
> The amount of really dumb driver boiler plate that this series
> obviously removes is exactly the sort of stuff we should be fixing by
> improving the core code.
> 
> The callback interface was never really sanely designed, it was just
> built around the idea of pulling the timout processing into the core
> code for TIS hardware. It should be revised to properly match these
> new HW types that don't have this kind of timeout mechanism.

Both TIS and CRB, which are TCG standards and they span to many
different types of drivers and busses. I don't have the figures but
probably they cover vast majority of the hardware.

We are talking about 39 lines of reduced complexity at the cost
of complicating branching at the top level. I doubt that there
is either any throughput or latency issues.

What is measurable benefit? The rationale is way way too abstract
for me to cope, sorry.

> Jason

BR, Jarkko