All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
To: jorge.ramirez@oss.qualcomm.com, peterhuewe@gmx.de,
	jarkko@kernel.org, jgg@ziepe.ca, sumit.garg@oss.qualcomm.com
Cc: linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org
Subject: [PATCH 0/1] tpm: TEE driver for a discrete TPM owned by OP-TEE
Date: Mon, 26 Oct 2026 17:32:47 +0100	[thread overview]
Message-ID: <20261026163259.1900439-1-jorge.ramirez@oss.qualcomm.com> (raw)

This adds a TEE-bus driver for a *discrete* TPM2 that is owned by OP-TEE and
exposed to the normal world through a passthrough pseudo TA. It binds the TA
by UUID and relays raw TPM2 commands, presenting a standard tpm_chip, so the
usual Linux TPM stack (IMA, trusted keys, tpm2-tools, the TSS) works through
/dev/tpm0 unchanged.

== Why this is needed ==
The chip sits on a bus that only the secure world can reach -- e.g. a SPI SE
whose controller is assigned to OP-TEE -- a deliberate hardening choice so the
normal world cannot observe or interpose on TPM traffic, and the engine cannot
be re-muxed to attack the chip. The normal world therefore has no path to the
controller at all: there is no tpm_tis_spi for Linux to bind. OP-TEE drives
the chip and this driver is the REE end of that channel.

== Relationship to tpm_ftpm_tee ==
The TEE transport shape mirrors the Microsoft fTPM driver's SUBMIT_COMMAND
(memref[0] = command in, memref[1] = response in/out), but this is a distinct
TA for a *real* chip, bound by its own UUID and opened with a REE-kernel login
(TEE_IOCTL_LOGIN_REE_KERNEL) so user space and other TAs cannot submit raw TPM
commands. Reusing the fTPM identity would conflate two different devices and
collide on a platform that has both. The common transport could later be
factored into a shared helper; that is left as a follow-up so it can be
reviewed with the fTPM maintainer rather than in this bring-up.

== Device-tree coexistence (important) ==
On a platform where OP-TEE owns the SPI SE, the *entire* non-secure SPI
controller node must be disabled in the kernel DT -- not just the tpm_tis_spi
child. If the normal-world controller stays enabled it drives the same engine
and corrupts OP-TEE's transfers. The Kconfig help spells this out.

== OP-TEE counterpart ==
The secure-world side (revert of the in-core TPM2 driver removal, a generic
TCG PTP SPI (TIS) transport backend, and the passthrough PTA this driver talks
to) is under review here:

  https://github.com/OP-TEE/optee_os/pull/8155

== Testing ==
Exercised on a Qualcomm Lemans EVK with an ST discrete TPM on a QUP SPI SE
owned by OP-TEE: the chip is detected and registered, and Linux drives it end
to end -- TPM2 identity and PCR reads over /dev/tpm0 round-trip correctly.
checkpatch --strict is clean and the module builds for arm64.

Jorge Ramirez-Ortiz (1):
  tpm: add TEE driver for a discrete TPM behind OP-TEE

 MAINTAINERS                     |   6 +
 drivers/char/tpm/Kconfig        |  18 ++
 drivers/char/tpm/Makefile       |   1 +
 drivers/char/tpm/tpm_dtpm_tee.c | 282 ++++++++++++++++++++++++++++++++
 4 files changed, 307 insertions(+)
 create mode 100644 drivers/char/tpm/tpm_dtpm_tee.c


base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
-- 
2.55.0


             reply	other threads:[~2026-10-26 16:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-26 16:32 Jorge Ramirez-Ortiz [this message]
2026-10-26 16:32 ` [PATCH 1/1] tpm: add TEE driver for a discrete TPM behind OP-TEE Jorge Ramirez-Ortiz
2026-10-26 20:07   ` Jarkko Sakkinen
2026-10-27  8:24     ` Jorge Ramirez
2026-10-27 13:10       ` 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=20261026163259.1900439-1-jorge.ramirez@oss.qualcomm.com \
    --to=jorge.ramirez@oss.qualcomm.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=sumit.garg@oss.qualcomm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.