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: <CAHk-=wgEszQD56Q2EZ83EhzJK+OnqPaAkUavfPWako2rA8Z4uA@mail.gmail.com>
Date: Mon, 6 Oct 2025 15:09:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jonathan McDowell <noodles@...th.li>
Cc: Jarkko Sakkinen <jarkko@...nel.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, 6 Oct 2025 at 14:40, Jonathan McDowell <noodles@...th.li> wrote:
>
> I'm not sure _reads_ make sense for the TPM device files at all. It's a
> command + response interface.

Yeah, I won't disagree. My main worry was one of "existing users doing
odd things shouldn't then get new semantics"

I don't actually _expect_ people to do odd things wrt /dev/tpm and
friends, but I've so often been surprised by the odd things that do
happen that...

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

Either of those likely is perfectly fine. Just ignoring it is the one
that adds the smallest possible ABI change, so in that sense it's the
"safer" option.

But you are probably right that there aren't any users that open that
thing read-only in the first place, much less then using O_EXCL.

Except I've seen programs that "work" by virtue of having done
entirely the wrong thing that just happened to work. Things like using
the wrong values entirely for 'flags' to open(), but the bits we cared
about happened to be ok, so...

And we have *traditionally* very much ignored O_EXCL when not paired
with O_CREAT (and even then it's iffy with NFS).

So people might just have random crud in the flags. That's why I
reacted originally: O_EXCL does make sense as a "open exclusively"
based on the name, but realistically we never actually *use* it that
way except for block devices.

So we *have* had those semantics for block devices, and they make
sense, and I don't mind the change at all per se.

But this is the kind of thing that I react to just because we have had
unexpected behavior in the past when a bit goes from "don't care" to
"meaningful".

Put another way: I'm probably just being unreasonably worried.

                     Linus