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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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