3. AUTOSAR Crypto Stack 三层架构：CSM、CRYIF、CRYPTO
好，咱们进入正题。AUTOSAR 的加密栈，说白了就是一套标准化的密码服务框架。它把上层应用和底层硬件（比如英飞凌的 HSM）隔开，让搞应用的人不用管底层用的是软件加密还是硬件加速。
这套架构分三层：CSM（Crypto Service Manager）、CRYIF（Crypto Interface）、CRYPTO（Crypto Driver）。我习惯把它们比作「调度中心」、「适配层」和「干活的人」。下面咱们一层层拆开看。
3.1 顶层调度：CSM（Crypto Service Manager）
CSM 是加密栈的入口，也是唯一对上暴露的接口。应用层（比如 SecOC、TLS、诊断模块）要加解密、算哈希、验签名，都通过 CSM 来发起请求。
CSM 的核心职责就两个：请求排队和作业调度。它不自己算密码，它只负责把任务派下去。
CSM 的关键特性：
- 异步处理：应用发一个加密请求，CSM 返回一个 Job ID，任务完成后通过回调通知。不会阻塞主循环。
- 优先级管理：可以给不同任务配不同优先级。比如安全启动的验签优先级，肯定比普通诊断报文的加密高。
- 密钥管理：CSM 维护一个密钥槽（Key Slot）表，应用通过 Key ID 引用密钥，不直接接触密钥材料。
我记得第一次调 CSM 时踩过一个坑：CSM 的 Job 配置里有个 JobType 参数，我随手配成了 CSM_JOB_TYPE_SYNC。结果上层应用一直等回调，系统直接卡死。后来查手册才发现，同步模式只能在中断上下文之外用，而且必须保证底层驱动能立即完成。嗯，从那以后我统一用异步模式，省心。
3.2 中间桥梁：CRYIF（Crypto Interface）
CRYIF 这层，说白了就是个适配器。它把 CSM 下发的标准化请求，翻译成底层 CRYPTO 驱动能理解的格式。
为什么要多这一层？你想想看，不同芯片的加密硬件差异很大。英飞凌的 HSM 是一套寄存器接口，NXP 的 SHE 是另一套，有些 MCU 甚至没有硬件加速，只能用纯软件库。如果没有 CRYIF 做抽象，CSM 就得为每种硬件写一套调度逻辑，那代码就乱套了。
CRYIF 的主要工作：
- 通道映射：把 CSM 的 Job 映射到具体的 CRYPTO 通道（Channel）。
- 密钥槽映射：把 CSM 的 Key ID 翻译成底层驱动能识别的密钥句柄。
- 错误码转换：把底层驱动的错误码转成 AUTOSAR 标准错误码。
一个小技巧：我在项目中习惯在 CRYIF 层加一个调试开关。开发阶段打开它，可以打印出每次加密请求的 Key ID、算法类型、数据长度。这样定位问题快很多，不用每次都去翻寄存器。
3.3 底层执行：CRYPTO（Crypto Driver）
CRYPTO 是真正干活的那一层。它直接操作硬件寄存器，或者调用软件加密库。
在英飞凌 TC3xx 系列上，CRYPTO 驱动主要做这几件事：
- 初始化 HSM：上电后配置 HSM 的时钟、中断、DMA 通道。
- 提交作业：把加密参数写入 HSM 的作业队列寄存器。
- 轮询/中断处理：等待 HSM 完成计算，读取结果。
- 密钥加载：把密钥从 NVM 加载到 HSM 的密钥 RAM 中。
CRYPTO 驱动通常分两种模式：
| 模式 | 特点 | 适用场景 |
|---|---|---|
| 轮询模式 | CPU 循环等待 HSM 完成，延迟低但占用 CPU | 短数据、高实时性要求（如 CAN 报文签名） |
| 中断模式 | HSM 完成后触发中断，CPU 可处理其他任务 | 大数据量、非实时场景（如固件加密） |
我曾经在一个项目里遇到过 CRYPTO 驱动死锁的问题。原因是中断优先级配得比调度器还高，结果 HSM 中断里调用了 OS 的同步原语，直接死锁。后来我把 CRYPTO 中断优先级降到调度器以下，问题就解决了。所以，中断优先级一定要和 OS 调度策略对齐，这个坑我替你们踩过了。
3.4 三层协作流程
这三层是怎么配合的？我画了一张图，你看一眼就明白了。
流程很简单：应用调 CSM → CSM 排好队发给 CRYIF → CRYIF 翻译成驱动指令 → CRYPTO 操作 HSM 硬件 → 结果原路返回。
3.5 配置要点与避坑
配置这套栈时，有几个地方容易出问题，我列一下：
- Job 数量别配太少：CSM 的 Job 池是静态分配的。如果并发请求超过 Job 数，后面的请求会被拒绝。我一般按最大并发量的 1.5 倍来配。
- 密钥槽大小要对齐：CRYIF 的密钥槽大小必须和 HSM 的密钥 RAM 大小匹配。配大了浪费内存，配小了密钥加载会失败。
- 中断优先级别乱设：CRYPTO 的中断优先级要低于 OS 调度器，高于普通外设。这个顺序搞反了，系统就等着死锁吧。
- 别忘了初始化顺序：先初始化 CRYPTO 驱动，再初始化 CRYIF，最后初始化 CSM。顺序错了，CSM 启动时找不到底层通道，直接报错。
⚠️ 重要提醒：CRYPTO 驱动里的超时时间一定要配合理。太短的话，大数据加密还没完成就超时了；太长的话，系统卡死时无法快速恢复。我习惯把超时设成「预期最大执行时间 × 3」，既留余量又不至于死等。
好了，AUTOSAR Crypto Stack 的三层架构就讲到这里。下一层一层的关系清楚了，后面讲具体集成时就不会晕。记住：CSM 管调度、CRYIF 管适配、CRYPTO 管执行，各司其职，别越界。