linux-kernel - Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18

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: <aOQ3V6M-wWQxxCWK@earth.li>
Date: Mon, 6 Oct 2025 22:40:39 +0100
From: Jonathan McDowell <noodles@...th.li>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>,
	David Howells <dhowells@...hat.com>, keyrings@...r.kernel.org,
	linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jonathan McDowell <noodles@...a.com>
Subject: Re: [GIT PULL] TPM DEVICE DRIVER: tpmdd-next-v6.18

On Mon, Oct 06, 2025 at 03:33:56PM +0300, Jarkko Sakkinen wrote:
> On Sun, Oct 05, 2025 at 11:24:09AM -0700, Linus Torvalds wrote:
> > On Sun, 5 Oct 2025 at 08:47, Jarkko Sakkinen <jarkko@...nel.org> wrote:
> > The exclusive access looks debatable to me too. I think you should
> > also require that the open was done not only with O_EXCL, but as a
> > write too.
> > 
> > Exclusive reads do not make sense.
> 
> True, I agree with this.

I'm not sure _reads_ make sense for the TPM device files at all. It's a 
command + response interface.

What should we do if we get O_EXCL and O_RDONLY? Return an error? Ignore 
the O_EXCL flag?

> After reading this email I realized also another issue with these patch
> when I tested them sequentially building a VM for each commit ID.
> 
> Without "tpm: Require O_EXCL for exclusive /dev/tpm access" applied,
> there's a regression: usually a daemon of some sort opens /dev/tpm0:
> 
> COMMAND      PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> tpm2-abrm 771444  tss    5u   CHR 10,224      0t0   94 /dev/tpm0
> 
> Without top patch this leaves /dev/tpmrm0 unusuable, which is a huge
> developer experience downgrade as it is nice and covenient device
> to try and do things. I.e. tail patch needs to be squashed and
> the whole patch set needs to be re-reviewed.

That's a fair point; I structured the patches in that fashion because I 
felt the O_EXCL patch was potentially contentious and might not be 
accepted.

> And based on this I'm happy to postpone O_EXCL changes to 6.19.
> Patch set just needs to be restructured better so that in-the
> middle of the series patches don't break things. And also it'd
> be better if this patch would be relocated as the first in the
> series: "tpm: Remove tpm_find_get_ops".

I'll spin a set with the tpm_find_get_ops removal first, then the O_EXCL 
patch, then the other two, which I think fixes all the ordering 
concerns.

J.

-- 
... Nice world. Let's make it weirder.