操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载本篇文章基于 doc/wg/cryptography/notes/cryptography-notes-2026-08-11.md 会议纪要展开聚焦 Tock 密码学 HILHardware Interface Layer演进的两大核心议题driver mutex 的引用计数方案如何避免多模态硬件上的死锁以及 Digest HIL 在移除 const generic 约束后的重设计方向。阅读本文后你将理解 Tock 内核中同步原语与 HIL 设计之间的张力以及密码学驱动在单模态/多模态硬件上的取舍逻辑。会议背景从上周 AES 讨论延续的同步议题本次会议是 Tock Cryptography WG 系列例会中的一环。在上一周的会议doc/wg/cryptography/notes/cryptography-notes-2026-08-04.md中工作组已经讨论了 driver mutex 这一新的异步锁机制它持有被保护的资源与内部簿记数据客户端请求访问时被加入队列到达队首后获得指向外设的智能指针。当时提出的两个悬而未决的难点是downcasting向下转型与reference counting引用计数。本周会议由 Bobby Reynolds 继续深入引用计数部分以软件 AES-CCM capsule 为案例展开随后由 Roy Bachynskyi 抛出 Digest HIL 的第一版重设计草案征求反馈。案例研究基于 ECB 的软件 AES-CCM capsuleBobby 以软件实现的 AES-CCM capsule 作为讨论起点。CCM 模式的全称是 CTR with CBC-MAC即由计数器模式CTR与 CBC 消息认证码CBC-MAC组合而成的认证加密模式。仓库中的实际实现位于 capsules/core/src/virtualizers/virtual_aes_ccm.rs其文档注释明确描述了这一结构该文件使用底层的 AES-CBC 与 AES-CTR 实现来加密/解密/认证 AES-CCM*并给出两次 AES 传递、一个重叠块即加密认证标签 U的数据布局示意。在该 capsule 的场景中硬件仅提供 AES-ECB 原语CBC-MAC 与 CTR 均由软件在 ECB 之上构造。若硬件自带 CBC-MAC 加速器则可直接用 ECB CBC-MAC 组合实现更高性能的 CCM。此时 capsule 需要同时获取两个硬件引擎ECB 与 CBC-MAC的访问权因此需要为每个硬件原语各持有一把 driver mutex并编写获取两个引擎智能指针的逻辑。单模态与多模态硬件为何需要 downcasting会议延续了上周关于硬件模态的讨论。存在两类典型芯片单模态离散硬件ECB 与 CBC-MAC 是独立的外设各有独立驱动与独立 mutex多模态硬件同一个引擎同时支持 ECB 与 CBC-MAC共享同一个驱动实例与同一把 mutex。在多模态情形下ECB 与 CBC-MAC 两种类型可能最终收敛为同一个具体类型这正是 downcasting 需求的来源capsule 持有的是类型擦除的 guard需要确认它是否就是期望的具体类型。Bobby 指出无论采用虚拟化器还是 mutexcapsule 本质上都必须序列化自己的硬件操作而在多模态硬件约束下这种序列化责任落到了 capsule 身上。死锁场景为何需要引用计数引用计数的直接动机是防止并发消费场景下的死锁。考虑一个 capsule 同时消费 2 个 AES 接口例如用于安全闪存存储每个接口各由一把 mutex 保护。在多模态硬件上若 capsule 先发起 AES 请求、再发起 HMAC 请求而第一个 AES 请求仍持有引擎则第二个 HMAC 请求永远不会返回 ready——因为多模态引擎的两次操作本质上是串行的没有序列化就会死锁。Tyler Potyondy 现场确认了引用计数的行为语义它并不是在重复获取 mutex 时返回错误而是两次请求都被授予然后各自递增引用计数。其避免死锁的关键在于不把客户端再次放入 mutex 队列从而避免同一客户端在队列中出现两次导致死锁。可以推断该方案的完整流程是客户端获取第一个引擎时被加入队列并计数继续获取第二个引擎时不再重复入队而是复用已有的队列位置与引用仅递增计数当所有引用被释放后mutex 才从队列中弹出该客户端。这一机制在 Bobby 所在的 Pluton 平台上已投入生产并成功避免死锁。引用计数的代价硬件细节向 HIL 泄漏Tyler 敏锐地指出了该方案的副作用capsule 现在持有两个引用ECB 与 CBC-MAC若正通过 ECB 引用执行加解密操作却通过 CBC-MAC 引用修改密钥材料或配置寄存器其行为将是未定义的。这意味着capsule 必须自行保证不执行这类非法操作而这实际上将部分硬件特性泄漏到了 HIL 之外。Bobby 承认这是一个根本性的危险fundamental hazard。工作组的目标本是通过 trait / HIL 抽象让 capsule 与具体硬件解耦、不必为不同硬件重写但引用计数方案要求 capsule 理解多模态硬件的串行约束并自行序列化。反过来若完全不做引用计数、只允许一次持有一把 mutex则 capsule 必须获取 ECB → 释放 → 获取 CBC-MAC → 释放交替进行而在两次获取之间其他驱动可能插入新的操作请求反而引入另一种死锁。结论是引用计数确实增加了一层复杂度需要强有力的理由才能成为默认实现。Tyler 将其定位为独立于 Mutex 之外、让 Mutex 更好用的一种便利特性代价是复杂度与潜在危害Bobby 也表示内部最初并未使用引用计数但很快在实际场景中遇到需要它的局面因此主张按需引入、避免过度设计。相关代码目前位于 Bobby 的 HIL 改动 WIP 分支中尚未合入本仓库主分支。Digest HIL 现状const generic N 的困境Roy Bachynskyi 随后介绍了 Digest HIL 的第一版重设计草案先回顾了问题根源。当前仓库中的 Digest HIL 定义于 kernel/src/hil/digest.rs其核心特征是以const DIGEST_LEN: usize作为编译期常量参数例如DigestDataa, const DIGEST_LEN: usize负责向哈希引擎喂入数据不可变数据用add_data可变数据用add_mut_data并通过ClientData回调返回结果DigestHasha, const DIGEST_LEN: usize数据装载完成后调用run计算摘要并通过hash_done回调返回DigestVerifya, const DIGEST_LEN: usize调用verify将计算结果与给定值比对通过verification_done回调返回布尔结果ClientDIGEST_LEN、ClientDataHashDIGEST_LEN、ClientDataVerifyDIGEST_LEN等组合型客户端 trait。问题在于const generic 把摘要长度编码进了类型系统使得一个驱动实例只能工作在某一固定模式。在多模态硬件如 stm32 与 lowrisc 上存在支持不同摘要长度的引擎上运行时切换摘要长度变得不可能而如果直接移除这个 const generic长度保证又会被转移给开发者同样不理想。此外Tock 当前支持 6 种哈希算法MD5、SHA-1、SHA-224、SHA-256、SHA-384、SHA-512外加 6 种 HMAC 变体仓库中通过Md5、Sha1、Sha224、Sha256、Sha384、Sha512、HmacMd5、HmacSha1、HmacSha224、HmacSha256、HmacSha384、HmacSha512等一系列set_mode_*trait 表达见 kernel/src/hil/digest.rs。若试图把这些全部塞进一个 struct扩展性同样堪忧。重设计草案分离算法与摘要、引入 DigestAnyRoy 的草案首先把算法与摘要两个概念分离随后将现有 trait 拆分为通用层与算法特定层新增通用 traitDigestAny提供给 capsule 使用——这一设计与 Bobby 的 Mutex 思路形成呼应引入DigestMode概念把摘要 token 传给任意外设同时允许 capsule/用户通过verify_mode()设置特定模式并取得 tokenClientDigestAny客户端无需任何改动。会议随后集中讨论了三个现有 trait 的去留DigestVerify 应从 HIL 中移除Bobby 回顾数月前工作组已就此达成结论——摘要验证verification通常是应用层关注点放在 HIL 层不合适。既然达成一致移除 Verify那么为只暴露 data 或只暴露 hash 而分离 trait的原有理由最小特权原则也随之瓦解DigestData 与 DigestHash 应当合并Hans Martin 指出现实中几乎没有只实现其中一个而不实现另一个的驱动Roy 也确认现有 HIL 客户端/用户并未给出分开的必要性且未遇到过这类硬件Alex 补充当初引入这两个 trait 的 PR 中有评论提及希望分离以保持最小特权、只向 capsule 暴露 data 或 hash但他同样赞成合并。现场全体达成一致在移除 Verify 的前提下DigestData 与 DigestHash 不再有分开的充分理由多模态与类型系统Bobby 提醒工作组此前围绕 AES 设计讨论时已倾向把更多信息编码进类型系统、减少运行时NOSUPPORT错误而 Digest 草案引入的DigestMode把错误从编译期推向运行期与 AES 讨论方向不一致虽在 Digest 场景下可能合理。Hans 则强调mutex 不应建模模态modality把两者混为一谈是rough waters同时指出草案中的大枚举只是把大 struct问题平移成了大 enum问题建议继续探索更好的封装设计模式。数据移动模式从 static buffer 走向回调驱动Bobby 提出一个与 Digest 草案交叉的观察与其使用SubSlice、DigestSlice或原始 static u8 buffer不如采用回调驱动的数据移动模式——由外设向客户端发起回调来请求数据。Tyler 概括其本质把缓冲区从 static buffer或 SubSlice 这类 static buffer 抽象改为传递标准 u8 slice。这一模式的好处是无需 statics同时消除了部分在所有权上难以推理的问题。Bobby 表示该模式与既有 AES HIL 草案的数据移动方向一致值得在 Digest 硬件上做思想实验验证Roy 承诺跟进研究。未来工作与 PR #5032 的处理会议明确了两条后续路线DigestSlice 设计Roy 下周继续推进DigestSlice提案——一个可被客户端与驱动共享、并带有大小保证的切片类型并融入既有的数据移动 WIP 模式同时计划用 driver mutex 实验哈希驱动。需要说明的是Tock 上游目前没有任何支持多模态摘要长度的硬件这给设计验证带来现实约束PR #5032 的取舍会议开场提到Roy 提交了为 Digest HIL 增加可选预设消息长度的 PRtock/tock#5032但其与现有 HIL 设计有点别扭属于 hot patch 式修复。Roy 本人倾向于等待重设计后的 HIL 落地再合入、暂时关闭该 PRBobby 则表示如果 OxidOS 团队确实急需此能力且缺失会构成上游阻塞鉴于改动量不大、不应让上游等待拖累对方他赞成先合并。小结本次会议清晰地呈现了 Tock 密码学 HIL 演进中的核心张力同步机制driver mutex 引用计数解决多模态硬件的串行访问与死锁问题但把序列化复杂度推给 capsule类型系统Digest 的 const generic 与 set_mode trait 族提供编译期保证却难以覆盖多模态硬件的运行时模式切换。Digest HIL 的重设计方向是分离算法与摘要、引入通用DigestAny、移除应用层关注的DigestVerify、合并DigestData/DigestHash并探索回调驱动的数据移动模式与带大小保证的DigestSlice。这些讨论仍在演进中相关实现细节可继续跟踪 kernel/src/hil/digest.rs 的演进以及后续工作组纪要与 PR 讨论。赞分享操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载相关推荐Tock 密码学工作组 2026-07-14 会议纪要深度解读AES HIL 设计之争、Oracle 加密路线图与 Digest 转向Tock 密码学工作组 2026 07 14 会议纪要深度解读AES HIL 设计之争、Oracle 加密路线图与 Digest 转向 导读 本文以 doc/操作系统嵌入式嵌入式OSTock 密码学工作组设计研讨实录Digest HIL 多模态化与基于 Driver Mutex 的新 AES HIL 提案Tock 密码学工作组设计研讨实录Digest HIL 多模态化与基于 Driver Mutex 的新 AES HIL 提案 本文基于 Tock Crypto操作系统嵌入式嵌入式OSTock 密码学工作组 2026-09-22 会议纪要Driver Mutex 落地、模算术 HIL 的类型安全设计与异步化评审流程Tock 密码学工作组 2026 09 22 会议纪要Driver Mutex 落地、模算术 HIL 的类型安全设计与异步化评审流程 本文是 Tock 嵌入式操作系统嵌入式嵌入式OS上一篇TuriX Skills技能系统教程用Markdown手册教会数字牛马点星GitHub附可直接套用的模板下一篇从零创建并提交一个 Awesome 精选列表完整流程、硬性门槛与规范实战指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考