From: Jonathan McDowell <noodles@earth.li>
To: Peter Huewe <peterhuewe@gmx.de>,
Jarkko Sakkinen <jarkko@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/4] pm: Ensure exclusive userspace access when using /dev/tpm<n>
Date: Mon, 20 Oct 2025 12:30:32 +0100 [thread overview]
Message-ID: <cover.1760958898.git.noodles@meta.com> (raw)
In-Reply-To: <cover.1758646791.git.noodles@meta.com>
I hit a problem where ~ 1% of TPM firmware upgrades were failing.
Investigating revealed the issue was that although the upgrade tool uses
/dev/tpm0 this does not actually prevent access via /dev/tpmrm0, nor
internal kernel users. It *does* prevent access to others via /dev/tpm0
So the upgrade process started, the HW RNG came in to get some
randomness in the middle, did the HMAC context dance, and confused
everything to the point the TPM was no longer visible to the OS even
after a reboot.
Thankfully I've been able to recover those devices, but really what I'd
like is the ability for a userspace tool to exclusively access the TPM
without something coming in behind it. Given the lightweight attempt at
locking that already exists I think this was the original intention.
I've reworked this series based on feedback received.
Firstly, it's been reordered TPM sharing functionality doesn't break
during bisection.
Secondly, the O_EXCL check has been tightend up to ensure the caller is
also opening the device O_RDWR. Callers shouldn't really be opening the
TPM except for reading + writing, but this should help guard against
unexpected flags usage a bit more.
Finally, this revision keeps the prohibition on more than one user of
/dev/tpm#, to avoid unexpected breakages for clients that expect this to
guard against multiple invocations. A client only then needs to use
O_EXCL if it wants to prevent *all* other access, even with
ContextSaves, such as the firmware upgrade case.
(I've sent a separate standalone patch that allows the TPM HW RNG to be
disabled at run time, and it's now in -next, but even with that I think
something like this is a good idea as well.)
Jonathan McDowell (4):
tpm: Remove tpm_find_get_ops
tpm: Add O_EXCL for exclusive /dev/tpm access
tpm: Include /dev/tpmrm<n> when checking exclusive userspace TPM
access
tpm: Allow for exclusive TPM access when using /dev/tpm<n>
drivers/char/tpm/tpm-chip.c | 90 +++++++++++++++----------------
drivers/char/tpm/tpm-dev-common.c | 8 +--
drivers/char/tpm/tpm-dev.c | 35 ++++++++++--
drivers/char/tpm/tpm-dev.h | 1 +
drivers/char/tpm/tpm-interface.c | 20 +++++--
drivers/char/tpm/tpm.h | 3 +-
drivers/char/tpm/tpm2-space.c | 5 +-
drivers/char/tpm/tpm_tis_core.c | 3 +-
drivers/char/tpm/tpmrm-dev.c | 20 ++++++-
include/linux/tpm.h | 4 +-
10 files changed, 124 insertions(+), 65 deletions(-)
--
2.51.0
next prev parent reply other threads:[~2025-10-20 11:43 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 17:26 [RFC PATCH 0/4] Re-establish ability for exclusive TPM access to userspace Jonathan McDowell
2025-09-02 17:26 ` [RFC PATCH 1/4] tpm: Ensure exclusive userspace access when using /dev/tpm<n> Jonathan McDowell
2025-09-03 19:22 ` Jarkko Sakkinen
2025-09-02 17:27 ` [RFC PATCH 2/4] tpm: Remove tpm_find_get_ops Jonathan McDowell
2025-09-10 16:54 ` Jarkko Sakkinen
2025-09-02 17:27 ` [RFC PATCH 3/4] tpm: Allow for exclusive TPM access when using /dev/tpm<n> Jonathan McDowell
2025-09-10 17:04 ` Jarkko Sakkinen
2025-09-02 17:27 ` [RFC PATCH 4/4] tpm: Require O_EXCL for exclusive /dev/tpm access Jonathan McDowell
2025-09-10 17:06 ` Jarkko Sakkinen
2025-09-23 17:09 ` [PATCH v2 0/4] Re-establish ability for exclusive TPM access to userspace Jonathan McDowell
2025-09-23 17:10 ` [PATCH v2 1/4] tpm: Ensure exclusive userspace access when using /dev/tpm<n> Jonathan McDowell
2025-09-24 1:14 ` Jarkko Sakkinen
2025-09-23 17:10 ` [PATCH v2 2/4] tpm: Remove tpm_find_get_ops Jonathan McDowell
2025-09-24 1:19 ` Jarkko Sakkinen
2025-09-23 17:10 ` [PATCH v2 3/4] tpm: Allow for exclusive TPM access when using /dev/tpm<n> Jonathan McDowell
2025-09-24 1:22 ` Jarkko Sakkinen
2025-09-23 17:10 ` [PATCH v2 4/4] tpm: Require O_EXCL for exclusive /dev/tpm access Jonathan McDowell
2025-09-24 1:23 ` Jarkko Sakkinen
2025-10-20 11:30 ` Jonathan McDowell [this message]
2025-10-20 11:30 ` [PATCH v3 1/4] tpm: Remove tpm_find_get_ops Jonathan McDowell
2025-10-20 11:30 ` [PATCH v3 2/4] tpm: Add O_EXCL for exclusive /dev/tpm access Jonathan McDowell
2025-10-20 11:30 ` [PATCH v3 3/4] tpm: Include /dev/tpmrm<n> when checking exclusive userspace TPM access Jonathan McDowell
2025-10-20 11:31 ` [PATCH v3 4/4] tpm: Allow for exclusive TPM access when using /dev/tpm<n> Jonathan McDowell
2025-10-20 11:53 ` Roberto Sassu
2025-10-23 14:24 ` Jonathan McDowell
2025-10-27 19:38 ` Jarkko Sakkinen
2025-10-27 20:09 ` James Bottomley
2025-10-27 20:18 ` Jarkko Sakkinen
2025-11-03 18:38 ` Jonathan McDowell
2025-11-09 4:34 ` Jarkko Sakkinen
2025-10-24 18:55 ` [PATCH v3 0/4] pm: Ensure exclusive userspace " Jarkko Sakkinen
2025-10-27 11:50 ` Mimi Zohar
2025-10-27 19:41 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1760958898.git.noodles@meta.com \
--to=noodles@earth.li \
--cc=James.Bottomley@hansenpartnership.com \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).