linux-kernel - Re: [PATCH v3 4/4] tpm: Allow for exclusive TPM access when using /dev/tpm<n>

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: <feb863c3e73f0b73b53d7d6f9889c79d37476855.camel@HansenPartnership.com>
Date: Mon, 27 Oct 2025 16:09:35 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jarkko Sakkinen <jarkko@...nel.org>, Roberto Sassu
	 <roberto.sassu@...weicloud.com>
Cc: Jonathan McDowell <noodles@...th.li>, Peter Huewe <peterhuewe@....de>, 
	Jason Gunthorpe
	 <jgg@...pe.ca>, Linus Torvalds <torvalds@...ux-foundation.org>, 
	linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org, 
	zohar@...ux.ibm.com
Subject: Re: [PATCH v3 4/4] tpm: Allow for exclusive TPM access when using
 /dev/tpm<n>

On Mon, 2025-10-27 at 21:38 +0200, Jarkko Sakkinen wrote:
> On Mon, Oct 20, 2025 at 01:53:30PM +0200, Roberto Sassu wrote:
[...]
> > Hi Jonathan
> > 
> > do I understand it correctly, that a process might open the TPM
> > with O_EXCL, and this will prevent IMA from extending a PCR until
> > that process closes the file descriptor?
> > 
> > If yes, this might be a concern, and I think an additional API to
> > prevent such behavior would be needed (for example when IMA is
> > active, i.e. there is a measurement policy loaded).
> 
> Also this would be a problem with hwrng.
> 
> This probably needs to be refined somehow. I don't have a solution at
> hand but "invariant" is that in-kernel caller should override user
> space exclusion, even when O_EXCL is used.

Also, are we sure we need O_EXCL in the first place?  A well
functioning TPM is supposed to be able to cope with field upgrade while
it receives other commands.  When it's in this state, it's supposed to
return TPM_RC_UPGRADE to inappropriate commands, so if we made sure we
can correctly handle that in the kernel, that might be enough to get
all this to work correctly without needing an exclusive open.

Of course, Field Upgrade is likely to be the least well tested of any
TPM capability, so there's a good chance at least one TPM out there
isn't going to behave as the standard says it should.

Regards,

James