Linux 6.3 To Support Pluton's CRB TPM2 On AMD Ryzen CPUs
The Microsoft Pluton security processor has been of concern to many Linux/open-source enthusiasts due to being a "black box" and plenty of unknowns around the provided root of trust, secure identity, secure attestation, and cryptographic services marketed by Pluton. Pluton has been found with AMD Ryzen SoCs since the 6000 mobile series but isn't found within the EPYC server processors.
Microsoft's Pluton security architecture overview.
Software security expert Matthew Garrett has been dabbling with Pluton since its debut and most recently has been working on getting its TPM2 device exposed under Linux. The TPM 2.0 Command Response Buffer (CRB) is a standardized interface from the OS kernel to communicate with the Trusted Platform Module that works regardless of architecture/TPM. But with Microsoft's Pluton, some changes to the Linux "tpm_crb" kernel driver are needed to get things working.
Garrett explained in the Linux TPM CRB patch enabling the Pluton support:
"Pluton is an integrated security processor present in some recent Ryzen parts. If it's enabled, it presents two devices - an MSFT0101 ACPI device that's broadly an implementation of a Command Response Buffer TPM2, and an MSFT0200 ACPI device whose functionality I haven't examined in detail yet. This patch only attempts to add support for the TPM device.
There's a few things that need to be handled here. The first is that the TPM2 ACPI table uses a previously undefined start method identifier. The table format appears to include 16 bytes of startup data, which corresponds to one 64-bit address for a start message and one 64-bit address for a completion response. The second is that the ACPI tables on the Thinkpad Z13 I'm testing this on don't define any memory windows in _CRS (or, more accurately, there are two empty memory windows). This check doesn't seem strictly necessary, so I've skipped that.
Finally, it seems like chip needs to be explicitly asked to transition into ready status on every command. Failing to do this means that if two commands are sent in succession without an idle/ready transition in between, everything will appear to work fine but the response is simply the original command. I'm working without any docs here, so I'm not sure if this is actually the required behaviour or if I'm missing something somewhere else, but doing this results in the chip working reliably."
The patch adding this support was picked up today by the linux-tpmdd.git "next" branch making this material as part of the TPM device driver changes slated for the upcoming Linux 6.3 cycle.
50 Comments
