可信嵌入式栈：内存安全不等于实时安全

嵌入式安全常被压缩成“不要用缓冲区溢出”。真实威胁还包括物理访问、侧信道、模型权重泄露、固件供应链和量子计算迁移。

Rust 的边界

Embedded Rust 调研显示，生态与 SAST 工具仍不成熟；MISRust 进一步说明，Safe Rust 能自动满足部分 MISRA 规则，但 unsafe、FFI 与硬件访问会重新引入风险。语言安全是必要条件，不是认证结论。

TinyML 的额外攻击面

TinyML 设备通常物理可达、内存极小，难以运行传统安全监控。模型权重可能编码敏感信息，查询接口可被用于模型窃取或对抗样本。安全设计需要从设备、模型和接口三层同时考虑。

PQC 与截止期

后量子签名与密钥封装带来更大的密钥、签名和计算量。若在控制回路中同步验证签名，必须把验证周期加入最坏响应分析。常用策略包括硬件加速、批处理、预计算和把安全操作移出硬实时路径。

可调度性

对一个固定优先级任务集，响应时间上界近似为：

$$R_i = C_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i}{T_j} \right\rceil C_j$$

安全操作增加 $C_i$ 后，必须重新迭代求 $R_i$。如果 $R_i > D_i$，系统即使“内存安全”也不满足实时要求。

实时安全预算 可以演示密码开销如何侵蚀截止期余量。结论必须建立在实测 WCET 和中断抖动上，而不是平均值。

威胁模型先于语言选择

嵌入式设备的安全目标通常包括：固件完整、密钥不泄露、模型不被篡改、传感器输入可信、调试接口受控、更新可回滚、故障可审计。选择 Rust 或添加 PQC，只是其中两个控制项。

一个最小威胁模型应明确：

资产	攻击者能力	失败后果
启动链与固件	物理接触、调试口、供应链替换	持久化后门、设备失控
密钥与会话	侧信道、内存转储、总线探针	冒充设备、解密数据
模型权重	提取、篡改、差分查询	知识产权损失、行为偏移
传感器输入	电磁/声学注入、虚假数据	错误控制、危险动作
更新通道	中间人、回滚、降级	远程执行、拒绝服务
日志与审计	删除、伪造、时间回拨	事故不可追溯

风险分析要覆盖设备生命周期：制造、密钥注入、部署、维护、退役。只在应用代码里做输入校验，无法解决调试口未关闭或旧固件可回滚的问题。

Safe Rust 能保证什么

Rust 的所有权、借用和生命周期检查消除了大量 use-after-free、double-free 和越界写风险，前提是代码留在安全子集。嵌入式场景常见的 unsafe 包括：

• 访问内存映射寄存器；
• 实现中断服务例程；
• 与 C 驱动或 RTOS API 的 FFI；
• 自定义 allocator 或 DMA 缓冲区；
• 跨核共享的无锁数据结构。

在这些边界上，仍需人工证明指针有效、对齐、生命周期和并发访问。MISRust 把部分 MISRA-C++ 规则映射到 Rust，说明语言检查可以覆盖许多静态规则，但安全认证还要求工具资质、需求追踪、编译器和运行时验证。Rust 编译通过不等于 ISO 26262、IEC 61508 或 DO-178C 合格。

TinyML 安全综述强调物理和模型侧风险：攻击者可能通过功耗、电磁、时序侧信道恢复权重，或通过恶意输入诱导错误分类。对可访问设备，还应考虑固件提取、调试接口、模型文件替换和通信协议降级。

PQC 的三组预算

后量子密码迁移至少要同时评估三组预算：

1. 计算预算：密钥生成、封装/解封装、签名/验证的周期与最坏执行时间；
2. 存储预算：公钥、私钥、密文、签名的静态和临时内存；
3. 通信预算：握手包大小、分片、重传与带宽。

ML-KEM、ML-DSA、SLH-DSA 等方案的参数集和实现差异很大，不能用一个“PQC 开销”概括。硬件加速可以降低周期，却增加面积与功耗；软件优化依赖指令集、栈使用和常量时间实现。若验证操作放在控制回路内，必须把最坏路径而不是平均路径加入响应时间分析。

对周期性控制，可采用签名批处理、预计算、会话复用或将验证移到非关键路径。但“移出关键路径”必须保证在验证完成前，设备不会执行危险动作。安全性与实时性不是二选一，而是需要在状态机中明确先后关系。

可调度性重新计算

固定优先级调度的响应时间迭代为：

$$R_i^{(n+1)} = C_i + \sum_{j \in hp(i)} \left\lceil \frac{R_i^{(n)}}{T_j} \right\rceil C_j$$

当 PQC 或安全监控增加任务 $i$ 的执行时间 $C_i$，或增加更高优先级中断，$R_i$ 会变大。若迭代不收敛或超过截止期 $D_i$，系统不满足实时性。还要检查栈峰值、Flash 占用、DMA 延迟和功耗恢复时间。

安全审计本身也可能成为负载。若每个传感器样本都同步签名并写日志，CPU 利用率会快速上升。可以采用环形缓冲、事件聚合或硬件安全单元，但不能牺牲证据完整性。

安全启动与密钥生命周期

安全启动需要不可变信任根、签名验证和防回滚计数。密钥注入应在受控环境完成，并记录设备身份、批次和权限。调试接口在量产设备上必须锁定或受认证保护；OTA 更新要检查签名、版本和恢复镜像。

模型文件应被视为敏感资产：它可能包含专有参数，也可能被替换以改变行为。对 TinyML 设备，至少需要完整性校验和授权更新。若模型在外部 Flash 中执行，还要考虑总线监听和读取保护。

设计顺序

1. 写出资产、攻击者和生命周期威胁模型；
2. 划分安全启动、运行时隔离、通信和更新边界；
3. 选择语言与 RTOS，但保留 unsafe/FFI 的审计清单；
4. 选择 PQC 参数集并测量周期、栈、密钥尺寸；
5. 将安全操作加入最坏响应时间分析；
6. 对物理侧信道、故障注入和供应链做红队测试；
7. 建立可回滚更新和事故审计流程。

结论

内存安全、实时性和后量子迁移是三条相互作用的约束。Rust 减少一类内存漏洞，TinyML 安全提醒物理和模型风险，PQC 改变计算与存储预算。真正的可信嵌入式栈，必须把这三者放进同一个状态机和同一张资源表，而不是分别宣传。

故障注入与侧信道

功能测试通过不代表安全。嵌入式设备应进行故障注入：电压毛刺、时钟毛刺、激光/电磁注入、断电重启和异常输入。攻击者可能跳过签名检查、改变条件分支或在启动早期泄露密钥。

常见防护包括：

• 关键条件双读与冗余比较；
• 故障检测与安全复位；
• 常量时间密码实现；
• 随机化与掩码；
• 独立安全域和只读密钥存储；
• 日志与远程证明。

这些机制会消耗面积、周期和功耗。需要在威胁模型下证明它们的收益，而不是机械堆叠。

安全更新的状态机

OTA 更新至少需要状态：当前镜像、待验证镜像、回滚镜像、更新计数和失败原因。流程应是：下载、签名验证、版本与防回滚检查、试运行、确认、提交。任何一步失败都应回到最后一个已验证状态。

若更新过程在关键控制期间进行，必须安排安全窗口，或使用双分区与原子切换。日志要记录谁发起、签名结果、版本和回滚原因，但不能泄露密钥。

模型与数据保护

TinyML 模型可能从设备固件中提取。敏感模型可用加密存储与安全启动保护，但推理时仍需解密到内存，物理攻击者仍可能观察总线。高价值模型可结合安全 enclave、内存加密和查询限速。

传感器数据可能包含隐私。设计要明确是否需要在设备端脱敏、聚合或差分隐私处理，以及日志是否保存原始样本。对医疗、车端和工业设备，数据保留周期和访问权限应与法规要求一致。

认证与证据

Rust、静态分析、单元测试、形式化证明和硬件安全模块都只是证据的一部分。安全认证通常要求需求追踪、工具资质、缺陷管理、配置管理和独立评估。团队应保留：

• 威胁模型与安全需求；
• unsafe/FFI 代码清单与审计记录；
• WCET、栈和功耗测量；
• 密码库版本与参数集；
• 更新与回滚演练；
• 漏洞响应和补丁验证。

这些证据应能说明“系统在什么假设下安全”，而不是只提供一张通过截图。

设计取舍

安全机制可能降低性能、增加内存或破坏兼容性。合理做法是按风险分层：低风险任务使用轻量校验，高风险写操作要求更强认证和人工确认；硬实时路径避免同步密码操作，非关键路径承担审计与更新。

最终目标是可验证的安全状态，不是最多的安全功能。每一项控制都应有对应威胁、失败模式和测试证据。

安全预算应和功能预算一样进入代码评审：新增一个密码调用、一个调试入口或一个模型更新路径，都可能改变实时性与攻击面。没有威胁模型对应关系的“安全补丁”不应默认增加。

上线前的测试矩阵应覆盖正常启动、密钥轮换、签名失败、断电恢复、最坏中断延迟和降级模式。每个安全特性都要有对应的可观测指标，例如验证耗时、失败次数、密钥剩余寿命和回退原因。把安全从“功能存在”变成“行为可验证”，才配得上可信嵌入式栈这个名字。

最终的信任链报告应明确每一层谁验证谁、失败如何关闭、密钥如何轮换、最坏延迟多少。无法回答这些问题的安全模块，只适合作为原型，不适合进入控制回路。

这份报告也应伴随固件与密钥版本更新，成为可追溯的安全基线。

如果安全机制无法在断电、时钟漂移或密钥失效时给出明确行为，它就不能进入硬实时控制路径。可信系统的标准不是“正常情况下安全”，而是异常时仍然可预测。

最后，把安全更新流程纳入发布演练：密钥轮换、固件签名、回滚和审计必须能在真实设备上完成。只在设计文档里存在、没有经过操作验证的安全机制，不能视为已经具备。

这应当成为每次固件发布前的固定验收步骤。

把安全更新当作可演练的工程流程，才能让信任链在真实故障中仍然成立。

安全功能的验收也应覆盖密钥丢失和回滚失败，而不是只验证顺利路径。

把异常路径当作第一等公民，嵌入式系统才真正可信。

安全预算与实时预算必须一起被验证，任何一项缺失都不能宣称系统已经达到生产级可信。

这也是进入下一轮验证的硬门槛。