操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载本文基于 Tock 核心工作组 2022 年 1 月 21 日的会议纪要 core-notes-2022-01-21.md 展开逐项还原当时围绕 ufmt 格式化库评估、基于凭据的多进程加载状态机、进程缓冲区Process Slice别名安全设计以及 Tock 测试基础设施的四场关键讨论。读者可以借此理解 Tock 内核在用户态代码体积优化、进程凭据验证与内存安全边界上的设计取舍并能从当前仓库源码中追踪这些讨论的最终落地形态。会议背景与参会成员本次会议是 Tock 核心工作组Core Working Group的例行周会参与者包括 Amit Levy、Brad Campbell、Philip Levis、Leon Schuermann、Hudson Ayers、Jett Rink、Johnathan Van WhyJVW、Pat Pannuto 等 Tock 长期维护者。会议议程分为五个部分Updateslibtock-rs 工具链与构建系统进展ufmt experience在 libtock-rs 应用中试验 ufmt 格式化库的结论AppID多进程凭据credentials加载状态机的实现状态Process Slice以运行时别名检查替代 ProcessBuffer 抽象层的设计讨论Testing for Tock集成测试、QEMU 与硬件 CI 的推进情况。这些讨论发生在 Tock 2.0 系统调用接口与 AppID 机制并行推进的时期会议的多数议题最终都沉淀到了当前仓库的 kernel 与 doc 目录中。Updateslibtock-rs 的构建与运行工具链会议首先由 JVW 与 Alyssa 报告 libtock-rs 的进展运行脚本libtock-rs 新增了一个脚本用于串联运行elf2tab并通过 QEMU 与 tockloader 执行生成的二进制主要服务于 2.0 系统调用接口下的测试场景构建系统为满足特定寻址要求libtock-rs 更新了构建系统使汇编器assembler与归档工具archive能够协同工作。会上提出的替代方案是直接使用 LLVM 工具链但当时认为可能缺少可用的汇编器汇编器 bug开发中遇到了汇编器对带注释 move 指令的处理缺陷。这一部分反映了 2.0 时代用户态工具链从编译产物到加载运行全链路打通的工程细节。对应的内核侧进程加载逻辑可以在 kernel/src/process_loading.rs 中查看TBFTock Binary Format头部解析则由 libraries/tock-tbf 提供。ufmt 格式化体验为减小二进制体积所做的取舍Hudson 报告了将ufmt一个面向嵌入式场景的 no_std 格式化库引入 libtock-rs 的试验结果。当时的目标是用它替代 Rust 核心core自带的格式化库从而在部分场景下减小二进制体积并提升性能。试验分为两个层面移植 ti50 应用将 ti50 系列应用改用 ufmt 格式化实测节省约13 kB二进制体积内核侧试验也在内核中尝试了使用 ufmt 的可能性。ufmt 的能力边界试验得出的关键限制如下能力ufmt 支持情况格式说明符仅支持普通Display、debugDebug与:#三种十六进制数字不支持数字格式化与填充工具多数不支持与 core 格式化库的兼容难以编写同时兼容 core 与 ufmt 的独立代码只能退回到 ufmt 极简接口会上确认若代码使用了 ufmt 不支持的格式化特性编译期即会报错fail at compile time这保证了不会出现运行期静默错误但也意味着代码必须主动限制到 ufmt 的子集内。体积与集成代价ufmt不是按需付费模型即使未使用某些特性整个库的二进制体积也会被完整计入因此若某个库没有采用 ufmt最终可能被迫同时携带 corefmt 与 ufmt 两份格式化实现后续计划开发 ufmt-extended 补充重要特性重点是十六进制数字格式化并重新评估代码体积影响对大多数应用而言ufmt 看起来是可用的。内核侧格式化的可行性讨论关于在内核中做格式化会议讨论了三种路径Debug 路径困难内核的 debug 类型复杂直接替换难度大简单类型可行但 syscall 增多对简单类型做格式化可行但会显著增加系统调用次数即使与 console 系统调用doc/syscalls/00001_console.md重叠使用仍可能需要更多 syscall宏展开时机通过宏实现时能在宏调用期完成多少工作尚不明确且需要把待打印对象的结构信息传入。从当前仓库源码看内核的格式化基础设施仍是core::fmt驱动内核打印实现集中在 kernel/src/debug.rs而进程内存的安全打印与访问则演化为下一节讨论的 Process Slice 体系。会议笔记中ti50 应用节省约 13 kB属于 Hudson 当时实测报告的数据读者可将其视为该试验阶段的结论而非通用承诺。AppID基于凭据的多进程加载状态机Phil 报告了 AppID 机制的实现进展用于加载多个进程含凭据与无凭据两种的状态机已经就位异步检查async checks暂时使用 dummy 实现占位等待 RSA 验证实现就绪后替换。对 Process 的三处改动为了让状态机工作会议提到对 process 进行了三处改动新增队列初始化任务函数queue init task fn两个凭据函数标记为通过mark as pass两个凭据函数标记为失败mark as fail。凭据工具链形态Brad 表示把凭据支持加入 tockloader 是直接了当的elf2tab可以在头部指定 footer 信息或者由 tockloader 负责插入。这界定了构建时嵌入凭据与烧录时注入凭据两种工作流的分工。代码体积的默认行为Hudson 的疑问是不使用凭据机制的板子要付出多少代码体积代价当时的结论是——目标是把代码组织成所有未使用特性都能被剔除elided的结构即零成本抽象。当前仓库中的落地实现这场讨论的成果在 kernel/src/process_checker.rs 中有完整体现设计规范则记录在 doc/reference/trd-appid.mdApplication IDs (AppID), Credentials, and Process Loading。从源码结构看最终落地的主要构件包括AppCredentialsPolicytrait定义板级策略——require_credentials()决定是否强制要求凭据check_credentials()发起对单个凭据的检查检查结果通过AppCredentialsPolicyClient::check_done()回调返回CheckResult枚举Accept(OptionCheckResultAcceptMetadata)接受并可附带不透明元数据、Pass跳过该凭据尝试下一个、Reject拒绝该凭据三种结果驱动状态机流转ProcessCheckerMachine实际的状态机实现check()从第一个 TBF footer 开始通过parse_tbf_footer逐个解析遇到不可检查的 footer 或NOSUPPORT/ALREADY错误时推进到下一个检查完全部 footer 后根据require_credentials()决定是CredentialsNotAccepted错误还是放行Ok(None)ProcessCheckErrorCredentialsNotAccepted、CredentialsRejected(u32)u32 为被拒凭据的索引第一个凭据为 0与InternalError三种错误类型AppUniqueness/Compress/AppIdPolicy确保两个具有相同 AppID 的进程不能并发运行并把被接受凭据压缩为ShortId默认()实现放行所有唯一性判断AcceptedCredential把 TBF footer 中存储的凭据与检查器附带的元数据绑定供 AppID 分配使用。对应的Processtrait 也提供了get_credential()kernel/src/process.rs用于在凭据被接受后取回该凭据。这套结构正是会议中状态机 占位异步检查 未用特性可剔除三项结论的源码级验证。Process Slice以运行时别名检查替代 ProcessBuffer 层Jett 提出移除ProcessBuffer抽象层改为在访问时做一次确保不发生别名aliasing的检查。任何对进程切片的无效可变访问都会失败检查发生在运行时。Phil 补充了时间点的权衡团队此前考虑的是在allow 系统调用时刻doc/reference/trd104-syscalls.md 所描述的 allow 机制做检查而非使用时。在use 时刻检查可能导致某些场景下出现异常失败而在allow 时刻检查则会引入开销约数百个周期hundreds of cycles。当前仓库的形态从当前源码看这场讨论最终在 kernel/src/processbuffer.rs 落地为进程缓冲区 进程切片双层结构内核把进程通过allow_read_write()/allow_read_only()传入的可读写、只读缓冲区映射为ReadWriteProcessBuffer与ReadOnlyProcessBuffer每次通过缓冲区结构访问内存时都需要一次liveness 检查确认进程内存仍然有效需要更传统接口的调用方可以把缓冲区转换为ReadableProcessSlice/WriteableProcessSlice使用但其生命周期受到约束——调用方不能持有这些切片的长期引用底层通过raw_processbuf_to_roprocessslice/raw_processbuf_to_rwprocessslice两个 unsafe 转换函数把指针长度表示安全地转换为 Rust 切片零长度缓冲区会被转换为合法的零尺寸切片即使指针为空。切片类型在胶囊层被广泛消费例如 capsules/extra/src/crc.rs、capsules/extra/src/ethernet_tap.rs、capsules/extra/src/ieee802154/framer.rs 等都使用了ReadableProcessSlice/WriteableProcessSlice接口。会议中运行时检查与数百周期开销的讨论对应到代码中就是每次访问前的有效性验证与使用期内的引用约束。Testing for Tock测试基础设施的推进会议最后讨论了 Tock 的测试策略明确提出了几个方向集成测试与胶囊单元测试为 capsules 补充单元测试当前 capsules 的测试资产分布在 capsules/core、capsules/extra 各 crate 中Litex 模拟已在使用的 Litex 模拟环境对应 CI 工作流为litex_sim.ymlQEMU已在使用的 QEMU 模拟环境相关使用说明见 doc/Qemu.mdlibtock-rs 2.0 支持即将完成用于在 2.0 接口下做用户态测试硬件 CI硬件在环测试正在推进中。其中 Litex 与 QEMU 模拟方案已经沉淀为仓库中的完整板级支持litex芯片与litex/arty、litex/sim板卡位于 chips/litex 与 boards/litexQEMU 相关板卡则包括 boards/qemu_rv32_virt、boards/qemu_rv64_virt、boards/qemu_arm_mps2 等可为内核与胶囊的回归测试提供无硬件环境。小结从会议讨论到源码落地2022-01-21 的这次核心工作组会议实质上是 Tock 2.0 时代若干关键机制设计决策的现场ufmt 试验划清了用户态格式化在体积收益与能力限制之间的边界AppID 状态机讨论直接塑造了 process_checker.rs 中策略、回调与错误处理的分层结构Process Slice 的别名检查方案演化为 processbuffer.rs 中缓冲区分层 生命周期约束的安全模型测试基础设施的讨论则对应着当前仓库中 Litex/QEMU 板级支持与胶囊测试资产的布局。读者在阅读这些会议纪要时可以沿着上述源码路径把历史讨论与当前实现一一对应起来。赞分享操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载相关推荐Tock 内核设计会议纪要解析软件 SHA-256、AppID 完整性检查与 Tock Registers 内存安全Tock 内核设计会议纪要解析软件 SHA 256、AppID 完整性检查与 Tock Registers 内存安全 2022 年 4 月 15 日召开的 T操作系统嵌入式嵌入式OSTock 内核 2024-01-26 核心工作组会议解读凭据检查与 AppID 解耦、PMP 重设计与进程加载架构演进Tock 内核 2024 01 26 核心工作组会议解读凭据检查与 AppID 解耦、PMP 重设计与进程加载架构演进 本文基于 Tock Core Work操作系统嵌入式嵌入式OSTock 内核内存安全与缓冲区抽象演进2022-05-27 核心团队会议纪要深度解读Tock 内核内存安全与缓冲区抽象演进2022 05 27 核心团队会议纪要深度解读 本文基于 Tock 项目官方核心团队会议纪要 core notes 20操作系统嵌入式嵌入式OS上一篇Zabbix 8.0 模板 SMART by Zabbix agent 2 active 详解基于 agent 2 主动模式的无脚本磁盘健康监控方案下一篇Introduction to Bash Scripting 实战用 SSMTP 让 Bash 脚本自动发送 SMTP 邮件与附件创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考