From: Jonathan McDowell <noodles@earth.li>
To: Peter Huewe <peterhuewe@gmx.de>,
Jarkko Sakkinen <jarkko@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>
Cc: linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [RFC PATCH 0/4] Re-establish ability for exclusive TPM access to userspace
Date: Tue, 2 Sep 2025 18:26:32 +0100 [thread overview]
Message-ID: <cover.1756833527.git.noodles@meta.com> (raw)
I hit a problem last week were ~ 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.
As an initial approach I propose this patch set; I don't think the first
2 patches are controversial, but the blocking of kernel access + switch
to O_EXCEL in patches 3 + 4 might be. I'm open to alternative
suggestions about how to achieve this.
(I've sent a separate standalone patch that allows the TPM HW RNG to be
disabled at run time, but even with that I think something like this is
a good idea as well.)
Jonathan McDowell (4):
tpm: Ensure exclusive userspace access when using /dev/tpm<n>
tpm: Remove tpm_find_get_ops
tpm: Allow for exclusive TPM access when using /dev/tpm<n>
tpm: Require O_EXCL for exclusive /dev/tpm access
drivers/char/tpm/tpm-chip.c | 90 +++++++++++++++----------------
drivers/char/tpm/tpm-dev-common.c | 8 +--
drivers/char/tpm/tpm-dev.c | 27 +++++++---
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 | 3 +-
10 files changed, 112 insertions(+), 68 deletions(-)
--
2.51.0
next reply other threads:[~2025-09-02 17:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-02 17:26 Jonathan McDowell [this message]
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-02 17:27 ` [RFC PATCH 3/4] tpm: Allow for exclusive TPM access when using /dev/tpm<n> Jonathan McDowell
2025-09-02 17:27 ` [RFC PATCH 4/4] tpm: Require O_EXCL for exclusive /dev/tpm access Jonathan McDowell
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.1756833527.git.noodles@meta.com \
--to=noodles@earth.li \
--cc=jarkko@kernel.org \
--cc=jgg@ziepe.ca \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterhuewe@gmx.de \
/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).