Page MenuHomeFreeBSD

tpm: crb: add support for the Pluton startmethod
Needs ReviewPublic

Authored by kevans on Tue, Nov 11, 1:55 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 20, 3:32 AM
Unknown Object (File)
Thu, Nov 20, 3:31 AM
Unknown Object (File)
Wed, Nov 19, 9:43 AM
Unknown Object (File)
Tue, Nov 18, 2:00 AM
Unknown Object (File)
Sun, Nov 16, 3:43 AM
Unknown Object (File)
Sun, Nov 16, 3:43 AM
Unknown Object (File)
Sat, Nov 15, 11:49 PM
Unknown Object (File)
Sat, Nov 15, 9:48 PM
Subscribers
None

Details

Summary

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.

Test Plan

Combinations tested:

  • Minisforum AI X1 (CRB + Pluton startmethod)
  • bhyve w/ swtpm (Traditional CRB)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 68532
Build 65415: arc lint + arc unit

Event Timeline

kevans created this revision.

Add missing size check to the startmethod _attach()

This might be because Juniper's code base isn't up to date with 16-current:
/w/main/src/sys/dev/tpm/tpm_crb.c:104:14: error: use of undeclared identifier 'ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON'

.acpi_sm = ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON,
           ^

/w/main/src/sys/dev/tpm/tpm_crb.c:151:25: error: invalid application of 'sizeof' to an incomplete type 'const struct tpmcrb_sm_cfg_map[]'

for (size_t i = 0; i < nitems(tpmcrb_sm_cfg_map); i++) {
                       ^~~~~~~~~~~~~~~~~~~~~~~~~

/w/main/src/sys/sys/param.h:321:26: note: expanded from macro 'nitems'
#define nitems(x) (sizeof((x)) / sizeof((x)[0]))

^~~~~

2 errors generated.

sys/dev/tpm/tpm_crb.c
590–591

No thrilled by non-ISO-C/non-BSD types being used. I guess you're trying to match our data types used (or ACPI specification data type definitions) somewhere in other ACPI code?

Hmm, the definition came in here:

commit 58308fadece25ae4c12bd2f4dce3d73d9c23be43
Author: Jung-uk Kim <jkim@FreeBSD.org>
Date:   Wed Apr 9 23:51:28 2025 -0400

    Import ACPICA 20250404
    
    (cherry picked from commit 97a7606d897edfa3089cb04eea70096a1f9cf734)
sys/dev/tpm/tpm_crb.c
590–591

Yeah,, I was initially trying to be consistent with other ACPI code, though I see that even sys/dev/acpica can't seem to decide which way we really want to be. On a second glance, though, uint*_t does seem to be more popular by a pretty large margin.