📚 课程目录第3章 HSM固件与宿主软件交互模型

3. HSM固件与宿主软件交互模型

在AURIX HSM HIL安全验证工程中，HSM（Hardware Security Module）并不是一个孤立运行的加密协处理器，它与宿主CPU（Host）之间通过一套明确的固件结构、通信接口和共享资源协同工作。理解这套交互模型，是后续设计HIL测试用例、注入故障、观测安全状态的前提。本节从HSM固件结构入手，逐步展开Host-HSM通信接口、共享内存、中断与邮箱机制，并给出验证场景中的典型交互路径。

一、HSM固件结构：从启动到服务

AURIX HSM通常基于独立的TriCore或ARM Cortex-M核，运行在隔离的电源域和时钟域中。其固件结构可划分为四个层次：

Boot ROM与启动加载层：上电后HSM核从专用Boot ROM执行，校验HSM固件镜像的完整性和真实性，然后跳转到固件入口。该层通常不可修改，是信任根的一部分。
HSM固件核心层：包含调度器、中断控制器、内存管理、消息队列管理。它负责接收Host请求、分派给具体服务、管理共享内存访问权限。
密码服务层：提供AES、SHA、ECC、RSA、TRNG等算法实现，以及密钥存储、密钥派生、安全启动校验等高级服务。该层通常以API形式暴露给Host，但实际执行在HSM内部。
Host接口层：定义Host与HSM之间的命令格式、响应格式、状态码和超时机制。它是Host软件唯一可见的HSM边界。

在HIL验证中，我们通常无法直接修改HSM固件，但可以通过Host侧驱动和共享内存内容来观测固件行为。因此，理解固件分层有助于定位问题：如果Host发送命令后无响应，可能是接口层队列满；如果响应返回错误码，可能是密码服务层密钥未加载。

二、Host-HSM通信接口：命令与响应

Host与HSM之间的通信采用“请求-响应”模型。Host将命令写入共享内存中的命令缓冲区，然后通过中断或邮箱寄存器通知HSM；HSM处理完成后，将结果写入响应缓冲区，再通过中断通知Host。典型命令格式如下：

typedef struct {
    uint32_t cmd_id;        // 命令标识，如0x01表示AES加密
    uint32_t param_len;     // 参数长度
    uint32_t param_addr;    // 参数在共享内存中的偏移
    uint32_t resp_addr;     // 响应缓冲区偏移
    uint32_t timeout_ms;    // Host期望的超时时间
} hsm_cmd_t;

命令ID是Host与HSM之间的契约。在HIL测试中，我们可以构造非法命令ID、超长参数、错误地址等异常输入，观察HSM是否返回预期错误码（如HSM_ERR_INVALID_CMD、HSM_ERR_PARAM），从而验证接口层的健壮性。

三、共享内存：数据交换的物理载体

共享内存是Host与HSM之间交换大量数据的主要方式。AURIX通常将一段SRAM划分为Host区域、HSM区域和共享区域。共享区域又细分为命令队列、响应队列、数据缓冲区和状态区。关键约束包括：

访问权限：HSM固件通过MPU配置，只允许HSM核读写共享区域，Host核只能读写Host区域和共享区域中的特定窗口。
一致性：由于Host和HSM可能同时访问共享内存，必须使用内存屏障或原子操作保证数据一致性。例如，Host写入命令后，需要执行__dsync()再触发邮箱。
缓冲区管理：通常采用环形缓冲区或双缓冲机制，避免Host写入时HSM正在读取。在HIL测试中，可以通过故意不释放缓冲区来模拟队列满，验证Host驱动的重试或报错逻辑。

四、中断与邮箱机制：通知与同步

中断和邮箱是Host与HSM之间的“门铃”。AURIX提供多种中断路由方式，常见的有：

Host→HSM中断：Host写入命令后，通过设置HSM中断寄存器触发HSM中断，HSM中断服务程序读取命令并处理。
HSM→Host中断：HSM处理完成后，通过设置Host中断寄存器通知Host读取响应。
邮箱寄存器：部分AURIX型号提供专用邮箱寄存器，Host写入数据后硬件自动置位，HSM读取后自动清零，适合传递短消息。

在HIL验证中，中断和邮箱是故障注入的重点。例如，可以屏蔽HSM→Host中断，观察Host是否超时；或者连续快速触发Host→HSM中断，测试HSM中断服务程序是否会发生重入或丢失。

五、验证场景中的交互路径

下面以一个典型的“安全启动校验”场景为例，说明Host与HSM的完整交互路径。Host需要校验应用固件的签名，流程如下：

Host将固件镜像地址和长度写入共享内存数据缓冲区。
Host构造cmd_id=0x10（校验签名）的命令，写入命令队列。
Host执行内存屏障，然后写邮箱寄存器触发HSM中断。
HSM中断服务程序读取命令，从共享内存读取固件数据，调用密码服务层进行SHA和ECC验签。
HSM将校验结果（通过/失败）和错误码写入响应缓冲区。
HSM触发Host中断，Host读取响应，决定是否继续启动。

在HIL测试中，我们可以针对每一步设计测试用例：篡改固件数据、伪造签名、在HSM处理期间复位Host、在响应到达前修改共享内存等。通过观测Host最终状态和HSM返回码，判断安全机制是否按预期工作。

上图展示了Host、共享内存和HSM固件三者的空间关系与数据流向。Host侧负责命令构造、邮箱触发和响应判断；共享内存是命令、数据、响应和状态的物理载体；HSM固件则通过中断服务程序、命令解析、密码服务和响应封装完成处理。图中箭头方向明确区分了“Host写入”“HSM读取”“HSM写入”“Host读取”四种操作，避免混淆。

在HIL测试中，共享内存和邮箱寄存器是可直接观测和注入的节点。例如，可以在Host写入命令后、HSM读取前，通过调试器修改共享内存中的参数，模拟数据篡改攻击；也可以屏蔽HSM→Host中断，验证Host超时处理逻辑。这些操作不需要修改HSM固件，非常适合在HIL环境中反复执行。

六、交互模型对验证工程的意义

掌握Host-HSM交互模型后，设计HIL测试用例就有了明确的“锚点”。我们可以把测试用例分为三类：

接口层测试：针对命令格式、命令ID、参数长度、地址范围、超时时间等，验证HSM接口层的输入校验和错误处理。
数据层测试：针对共享内存中的数据缓冲区，注入位翻转、截断、重放、篡改等故障，验证密码服务层的数据完整性保护。
通知层测试：针对中断和邮箱，模拟中断丢失、中断风暴、邮箱溢出等场景，验证Host和HSM的同步机制是否可靠。

例如，在安全启动校验场景中，一个完整的HIL测试用例可以这样设计：Host发送校验命令后，在HSM读取数据缓冲区之前，通过HIL平台修改缓冲区中的固件镜像一个字节，然后观察HSM返回的验签结果是否为失败，以及Host是否拒绝启动。如果HSM返回HSM_ERR_SIGNATURE且Host进入安全状态，说明该安全机制有效；如果HSM仍然返回成功，则说明存在安全缺陷，需要进一步分析是数据一致性保护不足还是验签逻辑被绕过。

总之，HSM固件与宿主软件的交互模型是HIL安全验证的“地图”。只有清楚命令从哪里来、数据放在哪里、中断如何通知、响应如何读取，才能有针对性地设计故障注入和观测点，让验证工作从“碰运气”变成“有章法”。