3、TPM软件栈与驱动：TSS软件栈架构与驱动加载
这一章我们聊聊TPM的软件栈。说白了，TPM芯片焊在主板上只是第一步，你得有软件去跟它对话。这个对话的桥梁，就是TSS（TPM Software Stack）和对应的驱动。
我早年调试一个国产TPM模块时，发现上层应用死活拿不到随机数。查了三天，最后发现是TDDL层的数据包长度字段填错了。嗯，从那以后我养成了一个习惯——不管上层出什么错，先拿逻辑分析仪抓一下TDDL层的报文。
3.1 TSS软件栈架构
TSS把TPM的访问分成了四层。每一层都有明确的职责。你想想看，如果没有分层，应用直接操作TPM寄存器，那安全性和可移植性就全没了。
核心观点：TSS分层的本质是「隔离复杂度」。上层应用不需要知道TPM是LPC接口还是SPI接口，下层驱动也不需要关心应用在做什么安全策略。
3.1.1 TSP（TPM Service Provider）
TSP是离应用最近的一层。它提供C语言接口，比如Tspi_ContextCreate、Tspi_KeyLoad这些。应用开发者只需要调用这些API，不用管底层怎么跟TPM握手。
我个人习惯在TSP层做一次参数合法性校验。为什么？因为有些上层框架传进来的密钥句柄是野指针，直接往下传会导致内核崩溃。我在项目中遇到过三次这种问题，后来干脆在TSP层加了个句柄有效性检查。
3.1.2 TCS（TPM Core Services）
TCS是承上启下的关键层。它负责三件事：
- 上下文管理：每个应用会话对应一个TCS上下文，隔离不同应用的TPM操作
- 命令序列化：TPM芯片一次只能处理一条命令，TCS负责排队
- 授权处理：PCR扩展、密钥使用等操作需要授权，TCS管理授权会话
避坑指南：我曾经调试过一个诡异的问题——两个进程同时访问TPM，结果PCR值总是不对。后来发现TCS层的命令队列没有做互斥，两条扩展命令交叉执行了。解决方案是在TCS层加一个互斥锁，确保命令原子性。
3.1.3 TDDL（TPM Device Driver Library）
TDDL是用户态和内核态的分界线。它把TCS下发的命令打包成固定格式的数据包，通过ioctl或read/write传给内核驱动。
TDDL层有一个容易被忽略的细节——字节序。TPM协议规定使用大端序，但x86平台是小端序。如果TDDL层不做转换，TPM收到的命令就是乱码。我记得有一次客户反馈TPM_GetRandom返回全零，查到最后就是TDDL层忘了调用htons。
3.1.4 TDD（TPM Device Driver）
TDD是真正的硬件驱动，运行在内核态。它直接操作TPM的寄存器，比如FIFO数据寄存器、状态寄存器、中断寄存器等。
不同接口的TPM，TDD的实现差异很大：
| 接口类型 | 寄存器访问方式 | 典型驱动 | 注意事项 |
|---|---|---|---|
| LPC | IO端口（0xFED40000） | tpm_tis | 需要ACPI表描述基地址 |
| SPI | SPI控制器寄存器 | tpm_tis_spi | 时钟频率不能超过10MHz |
| I²C | I²C从设备寄存器 | tpm_i2c_infineon | 地址冲突检测 |
3.2 Linux下tpm_tis驱动加载
Linux内核的TPM驱动框架很成熟。最常见的驱动是tpm_tis，它支持LPC接口的TPM芯片。我来说说它的加载过程。
3.2.1 驱动加载流程
- 设备枚举：ACPI表扫描到PNP0C31（TPM设备ID），触发驱动匹配
- probe函数：
tpm_tis_probe被调用，初始化寄存器基地址 - 硬件检测：读取TPM_ACCESS寄存器，确认TPM处于可用状态
- 超时配置：从TPM_CAPABILITY寄存器读取芯片支持的超时值
- 中断注册：如果支持中断模式，注册中断处理函数
- 字符设备创建：创建
/dev/tpm0设备节点
注意：如果/dev/tpm0没有出现，先检查dmesg | grep tpm。常见的失败原因是ACPI表没有正确描述TPM的基地址，或者BIOS禁用了TPM。
3.2.2 驱动加载验证
加载成功后，你可以用以下命令验证：
# 查看驱动是否加载
lsmod | grep tpm_tis
# 查看设备节点
ls -l /dev/tpm0
# 查看内核日志
dmesg | grep -i tpm
# 读取TPM版本信息（需要tpm2-tools）
tpm2_getcap properties-fixed我习惯在probe函数里加一个调试打印，输出TPM芯片的vendor ID和device ID。这样一眼就能看出驱动是否识别到了正确的硬件。
3.3 Windows TPM基元
Windows的TPM软件栈跟Linux不太一样。它把TPM操作封装成了基元（Primitives），上层通过Tbs.dll（TPM Base Services）来调用。
3.3.1 TBS架构
Windows的TPM基元分三层：
- TBS.dll：用户态DLL，提供
Tbsi_Context_Create、Tbsip_Submit_Command等接口 - TPM驱动：内核态驱动，
tpm.sys或tpmdrv.sys - 硬件抽象层：通过ACPI或SPI访问TPM寄存器
Windows的TPM基元有一个特点——它强制要求命令必须经过微软的签名验证。我记得有一次想用自定义命令测试TPM，结果TBS直接返回TBS_E_COMMAND_UNSUPPORTED。后来查文档才知道，Windows只允许经过WHQL签名的TPM命令通过。
3.3.2 常用基元接口
| 接口名称 | 功能 | 对应Linux操作 |
|---|---|---|
| Tbsi_Context_Create | 创建TPM会话上下文 | open("/dev/tpm0") |
| Tbsip_Submit_Command | 提交TPM命令并等待响应 | write/read /dev/tpm0 |
| Tbsi_Get_TCG_Log | 获取TPM启动日志 | sysfs /sys/kernel/security/tpm0/binary_bios_measurements |
| Tbsi_GetDeviceInfo | 获取TPM设备信息 | tpm2_getcap |
调试技巧：在Windows下调试TPM，可以用tpmtool命令行工具。运行tpmtool getdeviceinformation可以查看TPM状态。如果返回TPM_NOT_SUPPORTED，八成是BIOS里没开TPM，或者驱动没装好。
3.4 常见故障与诊断
最后，我总结几个我在项目中遇到的TSS层故障案例：
- 故障1：应用调用TSP接口返回0x80000001——这是TSP层参数校验失败。检查传入的上下文句柄是否为NULL。
- 故障2：TCS层命令超时——TPM芯片忙，或者命令队列满了。用
tpm2_getcap commands查看当前命令队列深度。 - 故障3：TDDL层通信失败——检查
/dev/tpm0的权限，或者内核驱动是否加载。我曾经遇到过SELinux阻止了TDDL的ioctl调用。 - 故障4：TDD层寄存器读写异常——用
devmem2直接读取TPM基地址的寄存器，确认硬件是否响应。
嗯，这一章的内容就到这里。TSS软件栈是TPM可信根的「神经系统」，每一层都有它的职责和坑。理解了这四层的分工，你就能快速定位TPM相关的软件故障。