系统与数据库2024arxiv.org
面向嵌入式系统的 Rust：现状、挑战与开放问题
Rust for Embedded Systems: Current state, challenges and open problems
进阶 · 约 50 分钟读完前置知识：嵌入式系统基础、Rust 语言基础、C/C++ 与内存安全
导读
这篇论文调查了 Rust 在嵌入式系统领域的应用现状、挑战与开放问题：Rust 的内存安全优势明显，但生态仍不完善。在 43 个 MCU 家族中，只有 16 个（37%）有可用的外设 crate，且大多由 svd2rust 自动生成；开发者放弃 Rust 的主要原因是 MCU 支持不足、与现有代码库集成困难以及组织与认证要求。论文还分析了 RTOS 中的 CVE 成因，其中越界写入占多数。
HN 关注点：HN 读者多为嵌入式开发者，讨论焦点是 Rust 在真实项目中是否已可用，以及生态、调试和 C/C++ 互操作等实际障碍。
HN 评论精选
这几条评论里：质疑 1 补充 2 亲历 1
亲历生态（外设驱动库）不完善是 Rust 嵌入式落地的最大障碍。
作为一名用 C++ 写嵌入式的 Rust 程序员，我认为阻碍采用的首要因素是生态。假设我用的 MCU 在 Rust 里支持得很好，那我想接一块常见的 OLED 屏，有对应的库吗？有的话能用吗？能用的话功能齐全吗？就算运气极好这些都没问题，那常见的陀螺仪芯片呢？当然，大概总有办法让 Rust 代码和 C 代码互操作，但要搞清楚这套做法是不是得花上一整天研究？我会时不时回来看看 Rust 嵌入式的进展，但目前 C++ 仍是我的首选。
atoav查看英文原文
As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC? Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research? I will certainly check back on the state of Rust on embedded every now and then, but as of now C++ is my goto.
补充真正的障碍是开发者高估 C/C++ 代码安全性、缺乏安全意识的教育问题。
这些都是 Rust 存在的真实问题，不过值得注意的是，文中提到的许多集成难题对用 C/C++ 写的外部代码同样成立。调查中有些回答也点出了我亲身经历过的一个最大障碍：Rust 存在教育问题。人们会严重高估自己 C/C++ 代码的正确性，低估达不到这种预期时失败的严重程度。我很少见到哪个项目稍微挖一挖找不出内存安全问题，即便是远比我高明的程序员也常犯低级错误。可惜当代码已经写好后我提出这些问题，常听到的回答是：“代码能跑，为什么要管这些理论上的问题？”
AlotOfReading查看英文原文
These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation. I've found very few projects where a bit of poking can't turn up memory safety issues. Even people who are far more skilled programmers than I am routinely write silly mistakes. Unfortunately the response I often hear to bringing these issues up after the code exists is "it's working code, why should I care about these theoretical issues?"
补充提炼论文关键数据：外设 crate 覆盖率仅 37%，以及放弃 Rust 的主要和次要原因。
我的要点：1）可用 arewertosyet.com 跟踪 Rust RTOS 及其状态；2）有把 C 转成 Rust 的工具（不过我不确定是否可信）；3）43 个 MCU 家族中只有 16 个（37%）有外设 crate，且大多由 svd2rust 生成；4）开发者考虑后放弃 Rust 的原因：MCU 支持不足（36%）、与现有代码库集成困难（32%）、组织约束与认证要求（30%）；5）第二大问题是调试（26%），这在预料之中，因为嵌入式系统是异步、事件驱动的设计，导致频繁的跨语言域交互，使调试变得困难。如果写个 while(1) 循环的应用都能轻松跑起来，我就会采用 Rust。
fusslo查看英文原文
my takeaways: 1. https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integrating with Existing codebase (32%) ; Organization constraints and certification requirements (30%)" 5. "The second major (26%) issue is debugging, which is expected because, as explained in Section 2, embedded systems follow an asynchronous and event-driven design. This results in frequent cross-language domain interactions and makes debugging hard." I would adopt rust if it were easy to get up and running just while(1) loop applications.
质疑从论文 CVE 数据出发质疑：若 81% 漏洞是越界读写，也许更简单的安全语言比全套 Rust 更划算。
论文虽专讲 Rust，但我觉得第 25 页的 CVE 分类图很有意思。看那些被归类为 Rust 能防止的 59 个 bug 的成因占比，我算出来是：越界读 18.6%；越界写 62.7%；空指针解引用 8.5%；释放后使用 5.1%；类型混淆、未初始化指针访问、内存泄漏各 1.5%。我很好奇这些比例能否推广到非 RTOS 编程。81% 的 CVE 归于越界读写（其中写占大头）很值得注意。有没有公开的其他 CVE 成因分析？如果跨应用与系统类型比例相似，那么在编程语言设计阶段就该做明确的成本收益权衡了。Rust 靠复杂的类型与生命周期系统实现内存安全，不少人希望能有更简单的“安全”语言。如果 80% 的 CVE 来自数组访问的读写错误，那么一门严格内存访问语义、但舍弃 Rust 生命周期与类型系统复杂性的语言，就能以极小代价防住很大一部分漏洞。另外若在类型系统里杜绝空类型，还能防住 90% 的……
throwaway17_17查看英文原文
The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder about the applicability of these percentages to non-RTOS programming. I find it very interesting that 81% of CVE's are allocated to Out-of-Bound Read/Writes, with writes being the larges percent of those obviously. Has there been any CVE cause analysis performed and publicly available? If so and the percentages bear out similarly to RTOS's across a spectrum of application/system types then there may be some clear cost/benefit analysis needed at the programming language design stage. Rust is a complex language with a complex type and lifetime system to achieve memory safety, and it is not an uncommon refrain that a simpler 'safe' language would be appreciated by many developers. If 80% of CVE's come from Read/Write errors on array access, then a language that enforces strict memory access semantics, but forgoes the rest of Rust's complexity regarding lifetimes and type system complexity would achieve a very large portion of exploit prevention at a minimal cost. Additionally, if you prevent Null types in the type system the language would then prevent 90% of CVE causes, again with a minimal amount of complexity. I'm not certain that the above is correct, if the percentages play out in the large, or that devs would actively switch to a considerably safer, while being simpler language. But it certainly is thought provoking.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2024Hacker News 讨论帖189 分 · 152 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选