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 (5):
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
hwrng: core - Allow runtime disabling of the HW RNG
drivers/char/hw_random/core.c | 9 ++--
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 +-
11 files changed, 118 insertions(+), 71 deletions(-)
--
2.51.0