2. AURIX HSM硬件架构与启动流程
AURIX 的 HSM（Hardware Security Module）并不是一颗外挂芯片，而是集成在 TC3xx SoC 内部的一个独立安全子系统。理解它的关键，是把它看成一个"芯片里的小芯片"：它有自己的 CPU 内核、自己的 ROM 与 RAM、自己的随机数源和密码加速器，也有自己独立的复位、时钟与电源域。Host CPU（即运行应用软件的 TriCore 主核）与 HSM 之间通过受限的共享存储与中断通道通信，而不是随意访问对方内存。这种"物理同片、逻辑隔离"的结构，正是 AURIX 能同时满足功能安全与信息安全要求的基础。
HSM 内部由哪些硬件单元构成
从硬件组成看，HSM 子系统通常包含以下几类单元。第一是 HSM 内核，在 TC3xx 上一般是一颗 ARM Cortex-M3，运行 HSM 固件，负责调度所有安全服务、管理密钥和访问控制。第二是 HSM 专用存储：一段 Boot ROM 存放不可修改的启动代码，一段代码 Flash 存放 HSM 固件，以及 HSM 私有的 SRAM 用于运行时数据与密钥缓存。第三是 密码加速器集群，典型包括 AES 加速器（对称加解密、CMAC/GMAC）、SHA 加速器（SHA-1/SHA-256 等哈希）、PK 加速器（RSA/ECC 等公钥运算），部分型号还带专用 TRNG 与密钥派生单元。第四是 TRNG（真随机数发生器），它基于物理噪声源产生熵，再经后处理与健康检测输出随机数，是密钥生成与会话随机数的信任根。第五是 与 Host 的通信接口，通常由共享 SRAM 邮箱、中断线和一组受保护的寄存器组成。
需要特别强调的是隔离机制：HSM 的存储与寄存器默认对 Host 不可见，Host 只能通过约定的邮箱窗口投递请求、读取响应。HSM 固件通过访问控制表决定"哪些服务允许被调用、哪些密钥允许被使用"，即使 Host 软件被攻破，也无法直接读出 HSM 内部的密钥明文。
启动流程：从复位到服务就绪
HSM 的启动与 Host 启动是并行但受控的。芯片上电或复位后，HSM 内核首先从自己的 Boot ROM 取指执行。Boot ROM 是掩膜 ROM，出厂即固化，无法被改写，因此它天然构成信任根。Boot ROM 的第一件事是检查 HSM 固件是否有效：它会读取固件镜像头部的签名与版本信息，用内置的公钥或哈希对固件做完整性校验。只有校验通过，才把固件搬运到 HSM 私有 SRAM 并跳转执行；校验失败则 HSM 停留在安全状态，不对外提供任何密码服务。
固件接管后，会依次完成 TRNG 初始化与自检、各加速器上电与复位、密钥存储区解锁、访问控制表装载，最后进入服务循环，通过中断通知 Host"HSM 已就绪"。Host 侧在启动早期通常只做一件事：轮询或等待这个就绪标志，然后再发起密钥加载或首次安全服务请求。这个顺序很重要——如果 Host 在 HSM 就绪前就投递请求，邮箱会返回忙或错误状态，而不是阻塞等待。
Host 与 HSM 的通信通道
Host 与 HSM 之间不是共享内存式的自由访问，而是典型的邮箱 + 中断模型。共享 SRAM 被划分为若干通道（channel），每个通道有固定的请求区和响应区。Host 把命令字、参数和输入数据写入请求区，然后写一个"门铃"寄存器触发 HSM 中断；HSM 固件读取请求、调用相应加速器或密钥操作，把结果写回响应区，再触发 Host 中断。Host 收到中断后读取响应并释放通道。
这种设计带来两个工程上的直接后果。其一是数据必须显式搬运：要加密 1 KB 数据，Host 需要把明文写入共享缓冲区，HSM 处理后再把密文读回，双方都要考虑缓冲区大小与对齐。其二是并发受限：通道数量有限，多任务同时请求密码服务时必须排队或复用，驱动层通常用信号量保护通道。实际项目中，AES 单块加解密经邮箱往返的延迟通常在几十微秒量级（具体取决于主频、通道配置与固件版本，此处为示例量级，非实测值），因此高频小数据加密应尽量批量提交，而不是逐字节调用。
工程上需要建立的三个认知
- HSM 是独立信任域：它的密钥和固件不因 Host 被攻破而泄露，Host 只能通过定义好的服务接口使用它。
- 启动有严格顺序：Boot ROM 校验固件是安全启动的根，任何固件签名或版本不匹配都会导致 HSM 不可用，而不是降级运行。
- 通信是显式且受限的：邮箱通道数量、缓冲区大小和中断延迟共同决定了密码服务的吞吐与实时性，架构设计阶段就要把它们纳入预算。