1. 课程导入

可信平台模块（Trusted Platform Module，TPM）是一颗独立或固件化的安全协处理器，用于完成密钥生成、平台度量、密封存储、签名与随机数产生等可信计算基础能力。在Linux系统中，TPM并不是一个“装完驱动就能用”的普通外设，它同时横跨硬件总线、内核驱动、字符设备接口、用户态协议栈、系统启动链与安全策略多个层面。理解TPM在Linux中的定位，是后续学习驱动移植、设备树配置、内核子系统、tpm2-tools与系统集成的前提。

从系统视角看，TPM位于“信任根”的位置：它向下依赖SPI、I2C、LPC等物理总线与固件描述，向上通过/dev/tpm0、/dev/tpmrm0以及内核tpm子系统暴露能力，再经由tpm2-tss、tpm2-tools、systemd-cryptenroll、IMA、measured boot等组件进入实际业务。也就是说，TPM驱动不是孤立模块，而是可信计算链路中的关键一环。

一、核心原理：TPM在Linux中的四层定位

TPM在Linux中的工作路径可以概括为“四层一链”。第一层是硬件与固件层，TPM芯片通过SPI、I2C或LPC总线接入SoC，固件通过ACPI表或设备树向内核描述其地址、中断与兼容字符串。第二层是内核层，Linux提供tpm核心子系统、tpm_tis与tpm_tis_spi等传输驱动，并注册字符设备。第三层是用户态协议层，tpm2-tss实现TCG TSS 2.0协议栈，tpm2-tools提供命令行入口。第四层是系统集成层，包括可信启动、磁盘加密、完整性度量与远程证明。

这条链路的关键在于“信任传递”：固件先度量引导组件，内核再度量内核模块与initramfs，用户态继续度量关键文件，最终把度量值扩展到TPM的PCR寄存器中。驱动层如果枚举失败、总线时序不匹配或资源管理器缺失，后续所有可信能力都会失效。

二、方法流程：从设备识别到功能验证

学习TPM驱动与系统集成，建议遵循一条可复现的验证流程。先确认硬件与固件是否暴露TPM，再确认内核是否加载驱动，最后验证用户态工具能否完成基本命令。

# 1. 查看内核是否识别 TPM
dmesg | grep -i tpm

# 2. 查看 TPM 字符设备
ls -l /dev/tpm*

# 3. 查看 sysfs 与驱动绑定
ls /sys/class/tpm/
cat /sys/class/tpm/tpm0/device/description

# 4. 使用 tpm2-tools 验证
tpm2_getcap properties-fixed
tpm2_pcrread sha256:0,1,7
tpm2_getrandom 16 --hex

如果dmesg中没有tpm_tis相关日志，应优先检查设备树节点、ACPI表、SPI片选与中断配置；如果设备存在但tpm2-tools报权限或资源错误，则应检查tpm2-abrmd、udev规则与用户组权限。

三、案例场景：嵌入式设备上的TPM集成

假设一块ARM嵌入式板卡通过SPI连接TPM 2.0芯片，设备树中需要描述SPI从设备、兼容字符串、时钟与中断。内核启动后，tpm_tis_spi驱动探测成功，生成/dev/tpm0。系统集成阶段，使用systemd-cryptenroll把LUKS2卷密钥绑定到PCR 7与PCR 11，实现开机自动解锁；同时启用IMA度量，把关键可执行文件哈希写入PCR 10。此时，TPM不再只是“安全芯片”，而是系统可信启动与数据保护的核心锚点。

四、误区与复盘：常见认知偏差

• 误区一：有TPM芯片就自动可信。实际上，若固件未度量、驱动未加载或PCR未扩展，TPM只是闲置硬件。
• 误区二：只关注应用层命令。驱动、总线、设备树与资源管理器任一环节出错，都会导致tpm2-tools失败。
• 误区三：忽略PCR一致性。固件更新、内核升级或引导配置变化都会改变PCR值，导致密封数据无法解封。
• 误区四：把TPM当普通存储。TPM内部NV空间有限，密钥与策略应通过密封和授权句柄管理，而不是直接存放大数据。

五、整体知识框架与实战路线图

本课程后续将沿着这条路线展开：先建立TPM 2.0与Linux子系统的整体认知，再进入总线驱动、设备树与ACPI配置，随后深入字符设备、资源管理器与TSS协议栈，最后落到可信启动、磁盘加密、完整性度量与远程证明等系统集成场景。掌握这条主线，就能把“TPM驱动”从零散命令提升为可设计、可调试、可集成的工程能力。