操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载Tock 密码学工作组在 2026-08-25 的例会纪要cryptography-notes-2026-08-25.md聚焦两大议题一是基于digest_hil分支的摘要/哈希硬件抽象层HIL重设计二是 Tock 中公钥密码学椭圆曲线、模算术、数字签名的基础设施现状。本文以该纪要为主体结合当前仓库中 digest HIL、HMAC/SHA-256 capsule、ECDSA 软件实现与public_key_crypto子系统的源码还原讨论脉络、澄清关键设计决策并给出可对照的仓库证据。读完本文你将理解 Tock digest HIL 的演进方向抽象化、driver mutex、数据移动模式、排队queuing语义的取舍以及公钥密码 HIL 设计中类型系统编码硬件能力与软件密码学迁移 userspace两条主线。一、会议背景与参与者本次会议是 Tock Cryptography WG 的例行周会参与者包括 Tyler Potyondy、Hans Martin、Roy Bachynskyi、Irina Bradu 与 Alex。Hans 首先澄清了上一周遗留的一个概念性问题driver mutex 并不定义驱动的组合模型composition model——组合模型与更上层的 API 都需要单独、谨慎地设计。这一澄清为后续关于 digest HIL 与 driver mutex 引入的讨论定下了基调mutex 只是并发互斥原语围绕它如何组织 capsule 之间的依赖关系才是工作组真正需要达成共识的部分。二、Digest HIL 重设计向抽象与简洁演进2.1 移除 dma buffer 方法让 HIL 更抽象Roy 在digest_hil分支上推进的 digest HIL 重设计第一项改动是移除 dma buffer 方法。在新的设计中调用方capsule自行分配一块缓冲区并在驱动初始化时把缓冲区传入由驱动在内部保存如果底层硬件需要 DMA驱动会直接使用这块已拥有的缓冲区。Roy 的评价是这让 capsule 代码变得干净得多——capsule 不再需要感知底层 DMA 缓冲区的存在与归属。这一改动与当前仓库主干中的 digest HIL 形成鲜明对照。现存的 kernel/src/hil/digest.rs 是完整的旧 HIL它把接口拆分为三个正交维度DigestData负责喂数据提供add_data不可变数据如 flash与add_mut_data可变数据如 RAM并通过set_data_client绑定ClientData回调digest.rsDigestHash负责出摘要run方法把结果写入调用方提供的[u8; DIGEST_LEN]缓冲区digest.rsDigestVerify负责比对摘要verify方法把计算值与调用方提供的compare数组比较digest.rs。三个维度又组合出Digest、DigestDataHash、DigestDataVerify三种聚合 trait客户端回调也细分为ClientData/ClientHash/ClientVerify并以 const 泛型DIGEST_LEN表达输出长度。这套结构本身已相当硬件无关而新分支的改动方向是把与 DMA 缓冲管理相关的细节进一步从接口中剥离让 HIL 更接近纯抽象。2.2 数据移动模式向[u8]与 Bobby 的 AES 设计靠拢Tyler 询问新设计中 client 侧如何把数据传给驱动Roy 的回答是现在只需传递[u8]。Tyler 认为这一形态与 Bobby 在 aes HIL 重设计中提出的数据移动模式data movement pattern非常接近。这意味着工作组正在把数据如何从 capsule 流入驱动、再流入硬件这一横切关注点收敛为统一约定——驱动持有缓冲区上层只提交切片引用从而把所有权与搬运细节集中在驱动一侧。从当前仓库看这种数据移动思想其实已有雏形旧 HIL 的add_data/add_mut_data均以SubSlice/SubSliceMut见 kernel/src/utilities/leasable_buffer.rs 对应的 leasable buffer 工具为载体允许调用方租借缓冲区的一段活动区间而不转移整个缓冲区的所有权新 HIL 只是把这一模式进一步简化为裸切片语义。2.3 driver mutex 与是否排队的语义之争Hans 关心驱动侧如何实现这套 HILRoy 指出实现位于 hash capsule 中并且该 capsule 使用 driver mutex。新 capsule 与上游 hash capsule 最大的行为差异是新 capsule不能排队多个操作——若已有操作进行中对应用户程序app直接收到BUSY。Roy 补充说这与他所知的 HMAC capsule 的行为不同现有 capsules/extra/src/hmac.rs 中的HmacDriver是支持排队的——它的 grant 中保存了pending_run_app: OptionProcessIdhmac.rs并通过check_queue()hmac.rs在每次操作完成回调后扫描所有 app 的待处理请求逐个派发当队列已满时会向新请求返回ErrorCode::NOMEM见command中对 run/update/verify 的处理hmac.rs。Roy 表示Bobby 的 AES 分支同样没有使用排队因此新 capsule 是基于该进行中work in progress版本写成的简单示例用以展示新 HIL 的形态。Tyler 的判断是AES capsule 处于进行中状态这可能是其暂不排队的副作用工作组虽尚未深入讨论但他预期未来希望 capsule 支持操作排队。随后他向 Hans 求证 Pluton微软的嵌入式安全平台中加密 capsule 的排队策略Hans 的回答是Pluton 通常默认不排队直接向 app 返回BUSY。Tyler 对此给出了一个很有价值的权衡总结值得完整保留不排队直接 BUSY适合内核上运行的应用已知且固定的场景——既然你清楚自己的负载就没必要为并发预留排队机制排队queuing在 Tock 更一般的场景下同一个内核镜像可能运行任意多个不同应用支持多应用排队作业、而不是把错误直接冒泡到用户空间是非常有用且重要的能力。这条讨论实际上触及 Tock 系统架构的核心哲学Tock 是一个面向未知应用组合的多租户嵌入式内核加密硬件是稀缺共享资源因此 capsule 层如何仲裁多个进程对同一密码引擎的访问直接决定了用户空间 API 的可用性。2.4 key 偏移处理与潜在密钥泄露风险Roy 指出新旧 capsule 之间还有一处偏移量offset处理的差异并主动提示了一个潜在安全风险STM 驱动要求从 capsule 侧把 key写两次capsule 可以向驱动传入任意大小的缓冲区这看起来是一种可能泄露 key 信息的方式——虽然当前实现中并未发生但可能是未来隐患的来源。Hans 进一步点出相关机制HMAC capsule 在每一轮pass之后会把 key 偏移量重置为零他提议跟踪 key phase密钥阶段。Roy 的设想是在 capsule 中引入一个枚举enum来限制驱动读取 key 的次数Hans 认为这有助于防止错误地静默重放密钥an error silently replaying a key并主动表示可以着手研究。对照现有代码HmacDriver中确实存在与 key 生命周期相关的设计痕迹key 通过ro_allow::KEY缓冲区从用户空间读入被拷贝进TMP_KEY_BUFFER_SIZE512/8 64 字节的临时缓冲区后传给set_mode_hmacsha*hmac.rshash_done/verification_done回调中都会调用self.hmac.clear_data()清理底层密钥状态hmac.rs。会议讨论的密钥阶段跟踪 读取次数限制可以视为对这一机制的强化即便驱动实现出现缺陷capsule 层也能从状态机层面阻止密钥被意外重放或越界读取。2.5 新旧 HIL 的去留替换还是并存关于上游化upstreaming计划Roy 提出或许可以保留现有 HIL同时新增一套标记为 deprecated 的新 HIL理由是 OpenTitan 仍在使用旧 HIL而他暂时没有测试手段去验证对 OpenTitan 驱动的改动。Tyler 的态度非常明确应该只有一个 HIL新 HIL 应当直接替换旧的。理由有二OpenTitan 的测试问题可以请 Kat 协助解决更一般地在另一套硬件上实现该 HIL本身就是检验 HIL 设计是否真正硬件无关hardware agnostic的好方法——若接口只能在单一驱动上成立说明抽象还不充分。Hans 表示同意认为应当彻底替换旧 HIL。这里需要说明纪要中讨论的digest_hil分支位于 Tock 主仓库之外由参与者维护的个人 fork因此新 HIL 的最终形态尚未出现在本仓库主干中当前仓库可验证的仍是以 kernel/src/hil/digest.rs 为代表的旧接口。同样纪要中反复出现的 driver mutex 模式从当前 kernel 与 capsules 的源码结构看尚未落地未检索到对应实现这恰好印证了 Tyler 的判断——该工作将是第一个把 driver mutex 模式引入 Tock 主干的工作需要等 Bobby 和 Amit 回归后继续讨论 mutex 语义并推进上游化。Roy 确认改动范围基本就是新 digest HIL 对应的驱动与 capsule 更新。三、Tock 公钥密码学现状模算术 HIL 与签名基础设施3.1 数字签名基础设施与既有 capsuleAlex 正在推进数字签名digital signature基础设施他注意到 Kat 去年曾提交过相关 capsule。从当前仓库结构看确实存在两块与之呼应的实现软件 ECDSA 实现capsules/ecdsa_swREADME 见 capsules/ecdsa_sw/README.md基于 RustCrypto 生态实现 ECDSA目前支持P256secp256r1签名验证包含p256_verifier.rs、p256_signer.rs及配套测试 capsules/ecdsa_sw/src/test/p256.rs签名验证 HILkernel/src/hil/public_key_crypto/signature.rs 定义了以HASH_LEN/SIGNATURE_LEN为 const 泛型的SignatureVerify/ClientVerify与ClientSign接口。可以推断从源码结构看Alex 提到的Kat 去年的 capsule与上述签名验证相关实现有直接关联其当前工作则更进一步——研究椭圆曲线与模算术的 HIL目标是产出ECDSA capsule 签名的 capsule/草案。3.2 模算术 HIL内存中的 calculator 与更小粒度的替代方案Alex 对模算术 HIL 的构想是一个存储在内存中的计算器calculator并复用工作组一直在探讨的数据移动模式即 2.2 节讨论的驱动持有缓冲区、上层提交数据切片的方式。Hans 询问是否考虑更小粒度的接口例如只做模幂运算modular exponentiationAlex 表示可行但他更关注支持更复杂运算的算法。这一点在当前仓库中已有直接对应物kernel/src/hil/public_key_crypto/rsa_math.rs 定义了RsaCryptoBase/RsaCryptoBaseMut两个 trait核心原语正是mod_exponent——计算(message ^ exponent) % modulus通过mod_exponent_done回调返回结果。其约束modulus长度必须是 2 的幂并决定运算长度、result缓冲区不得小于modulus、消息与指数缓冲区可大于运算长度为模算术硬件能力如何抽象提供了 Tock 现有的参考实现。可以推断Alex 设想的通用模算术 HIL 会与rsa_math存在能力重叠或演进关系也可能以 trait 组合的方式覆盖更广的椭圆曲线运算。3.3 把硬件属性编码进类型系统减少运行时 NOSUPPORTTyler 对这份 HIL 草案的关键反馈是应当把更多硬件属性编码进类型系统type system。他给出的背景是工作组已在普遍讨论这一点而模算术正是典型案例——如果不做类型级约束实现会面临大量运行时的NOSUPPORT错误。Alex 认同并计划改用 trait 机制实现类型层面的强制约束。这一建议在现有 HIL 中的确能找到运行时 NOSUPPORT的现实证据旧 digest HIL 的run/verify及hash_done/verification_done回调都明确把NOSUPPORT列为合法错误码例如 digest.rs用于表达当前选择的摘要算法不受支持当硬件只实现了 SHA-256 而用户请求 SHA-512 时错误只能在运行时暴露。若把支持哪些算法/哪些模运算模式编码为 trait 约束或 const 泛型能力标记这类错误就能在编译期被排除代价是 trait 组合随硬件能力矩阵膨胀。这正对应 Tyler 与 Alex 讨论的取舍点。3.4 软件密码学从内核迁往用户空间Tyler 特别强调了对软件密码学支持的长期关注随着更复杂且硬件支持可能更差的密码算法被引入Tock 需要一个完善的软件密码学方案。工作组此前讨论过的方向是把内核中的软件密码学整体迁移到用户空间并已有 PR会议记录中提到编号 4869 的 PR提供一种把用户空间服务暴露给内核的机制。会议记录强调这些讨论与具体 HIL 关系不大但对扩展更复杂密码算法支持很重要。从仓库现状看软件密码学存在于内核仍是现实例如 capsules/extra/src/sha256.rs 提供了纯软件 SHA-256 实现Sha256Software基于 64 个轮常量与 32 位原生字运算通过DeferredCall完成异步回调见 sha256.rs它同样实现了完整的DigestData/DigestHash/DigestVerify接口sha256.rs软件 ECDSAcapsules/ecdsa_sw同样以内核内 capsule 形式存在。Tyler 提出的迁移方向意味着未来这些实现可能以用户空间服务 内核代理的新形态出现。Alex 则表达了对软件密码学实现的顾虑由于他已经找到了可用的硬件加速器他认为当前更适合把精力放在为 Tock 增加硬件支持上——这与软件实现兜底、硬件实现优先的嵌入式安全实践一致。四、结论两条工作线的前景综合本次纪要可以梳理出 Tock 密码学子系统正在并行推进的两条主线Digest/HMAC 基础设施现代化以digest_hil分支为载体推动 HIL 抽象化移除 DMA 缓冲细节、数据移动收敛为[u8]、引入 driver mutex 互斥语义、在排队 vs 直接 BUSY之间为多租户场景保留排队能力同时通过密钥阶段跟踪与读取次数限制加固密钥生命周期安全并最终以新 HIL 替换旧 HIL的方式完成上游化——跨硬件如 OpenTitan的实现与测试将是验证 HIL 硬件无关性的关键一步。公钥密码学能力扩展以模算术/椭圆曲线 HIL 草案为起点把硬件能力编码进类型系统以减少运行时NOSUPPORT同时为更复杂、硬件支持欠佳的算法规划软件密码学路径长期方向是迁往用户空间并以内核可调用的服务形式存在。对于想要参与或跟进这些工作的开发者当前仓库中最相关的阅读起点是kernel/src/hil/digest.rs旧 digest HIL 全貌、capsules/extra/src/hmac.rs带排队的 HMAC capsule 参考实现、capsules/extra/src/sha256.rs内核内软件 SHA-256、kernel/src/hil/public_key_crypto公钥密码 HIL 与 RSA 模幂原语以及 capsules/ecdsa_sw/README.md软件 ECDSA 现状。后续各期会议纪要与工作组成果可继续在 doc/wg/cryptography/notes 目录中追踪。赞分享操作系统嵌入式嵌入式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/操作系统嵌入式嵌入式OStradingview-mcp 贡献指南为 Claude Code 与 TradingView Desktop 的本地桥接层安全地添加功能tradingview mcp 贡献指南为 Claude Code 与 TradingView Desktop 的本地桥接层安全地添加功能 导读 本文是 tr操作系统嵌入式嵌入式OSTock 用户态服务与 IPC 共享内存设计解析Network WG 2026-08-31 会议技术讨论Tock 用户态服务与 IPC 共享内存设计解析Network WG 2026 08 31 会议技术讨论 本文基于 Tock 内核仓库中 Network Wo操作系统嵌入式嵌入式OS上一篇IoT-For-Beginners 智能定时器多语言支持在 Raspberry Pi 上调用 Translator 服务实现语音文本翻译下一篇Google Mock 速查手册miniblink49 中 C 模拟类的定义、期望、匹配器与动作全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
