src/sys/dev/tpm, branch main

tpm: fix multi-threaded access with per-open state

2026-03-20T18:48:44Z

The TPM driver currently has a single buffer per instance to hold the result of a command, and does not allow subsequent commands to be sent until the current result is read by the same OS thread that sent the command, with a timeout to throw away the result after a while if the result is not read in a timely fashion. This has a couple problems: - The timeout code has a bug which causes all subsequent commands to hang forever if a different OS thread tries to read the result before the OS thread which sent the command, and the OS thread which sent the command never tries to read the result. - Even if the first problem is fixed, applications expect to be able to read the result from a different OS thread than the OS thread which sent the command. The particular case that we saw was a go application where the go runtime scheduled the goroutine which read the result to a different OS thread from one where the goroutine that sent the command ran, and there's no way to force these to always run on the same OS thread. Fix all of this by replacing the global result buffer with a per-open result buffer via devfs_set_cdevpriv(), so that we no longer need to block subsequent commands until the results of a previous command are retrieved or care about which OS thread is reading the result of a command. Sponsored by: Netflix Reviewed by: olivier, imp Differential Revision: https://reviews.freebsd.org/D52328

chore: replace {0, 0} with {DEV,KOBJ}METHOD_END

2026-02-25T05:59:34Z

Both of the aforementioned macros have been present in FreeBSD for well over a decade: 2009 for `KOBJMETHOD_END`; 2011 for `DEVMETHOD_END`. Adapt all hardcoded references of `{0, 0}` with `DEVMETHOD_END` and `KOBJMETHOD_END` as appropriate. This helps ensure that future adaptations to drivers following patterns documented in driver(9) can be made more easily/without issue. MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D55414

tpm20: fix suspend/resume and entropy harvesting

2026-02-05T03:35:10Z

There were a few problem here: - TPM2_Shutdown results in a response that we need to either process or ignore, otherwise any tpm20_write or tpm20_harvest call will trivially hang on an `sc->pending_data_length != 0` - We should have a matching TPM2_Startup upon resume to restore any state that should have persisted - We must drain the harvest task before we suspend to avoid problems there This commit is sufficient to avoid breaking suspend/resume. PR: 291067 Fixes: a2d5ed9442bb ("Introduce driver for TPM 2.0 in CRB and [...]") Fixes: 4ee7d3b0118c ("Allow using TPM as entropy source.") Co-authored-by: markj (D53835) Tested by: garga Differential Revision: https://reviews.freebsd.org/D55074

tpm: crb: add support for the Pluton startmethod

2026-02-03T04:48:32Z

The Pluton startmethod uses a simple doorbell mechanism to wakeup the TPM unit after we've issued various forms of state change, with the registers to use specified in the startmethod-specific segment of the TPM2 table (up to 12 bytes after the StartMethod). At the very least, this is the kind of TPM in use by my AMD Zen 4-based Minisforum machine. Differential Revision: https://reviews.freebsd.org/D53683

tpm: crb: factor out idle/ready state transitions

2025-11-15T02:22:10Z

Some TPM implementations have a different start method that requires an additional notification for some state changes; for instance, the "Pluton" start method. Just factor these transitions out for now, and the coming commits will introduce points that the start method can hook in at. Reviewed by: obrien Differential Revision: https://reviews.freebsd.org/D53682

random: git'o in RANDOM_ENABLE_TPM

2025-11-11T02:46:31Z

Fixes: 3deb21f1a

random: TPM_HARVEST should have been named RANDOM_ENABLE_TPM

2025-11-10T20:54:48Z

* Enable RANDOM_ENABLE_TPM by default * The commit of TPM_HARVEST failed to add it to NOTES so that the LINT kernel would build the code. Fixes: 4ee7d3b0118c82e651712bb65da53d08e78cd7b1 Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D53460

random: Make the entropy source registration interface more uniform

2025-09-08T15:21:43Z

Most pure sources work under a "pull" model wherein a dedicated thread polls the source at regular intervals (every 100ms). A couple of sources, however, will instead call random_harvest_direct() to provide entropy samples. Such sources were not calling random_source_register() and thus weren't in the global random source list. Modify "push" sources to use random_source_register() like other sources do. Such sources omit an implementation of rs_read and are thus skipped by the above-mentioned thread. This makes it easier to allow pure sources to provide a min-entropy estimate in a uniform way. Reviewed by: cem MFC after: 2 weeks Sponsored by: Stormshield Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D52229

TPM: Add hint check to skip TPM IRQ configuration

2025-08-29T17:56:25Z

Added use_polling hint check in tpm tis driver attach routine to skip TPM IRQ configuration and to use TPM poll method to get TPM operation status Reviewed by: imp Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D52048

tpm: Register TPM as entropy source

2024-08-31T17:53:02Z

TPM is defined as an entropy and is called every 10 seconds. However it was not registered and calls were discarded. Signed-off-by: Jean-François Hren MFC after: 1 week Pull Request: https://github.com/freebsd/freebsd-src/pull/1398