crustc：把整个 rustc 翻译成 4600 万行可构建 C 代码，还能用 GCC + make 跑起来

这个项目最抓眼球的地方，不只是“Rust 编译器能编成 C”，而是作者真的把 整个 rustc 翻成了一套可以 直接用 GCC 和 make 构建 的产物。仓库里给出的演示路径相当直接：只要补上匹配版本的 LLVM 动态库，执行 make，最后就能跑出一个能打印版本号、还能继续编译 core / alloc / std 的可用 Rust 编译器。

背后的核心是作者做了三年的 Rust→C 工具链尝试，最新一版叫 cilly。它不是简单把 Rust 语法“降级”成某种通用 C，而是会针对目标 C 编译器和平台能力生成 witness programs，探测 _Thread_local、类型布局、对齐、字符编码、整数表示等细节，再为具体编译器吐出更合适的 C 代码。也就是说，这条路线的目标并不是“让现代 Linux 上多一种编译 Rust 的奇观”，而是把 Rust 带到那些 没有 LLVM / GCC 支持、但仍然能跑 C 编译器 的老系统、怪平台和冷门目标上。

作者还给出了一些很有传播性的细节：这次仓库只是完整工具链的 demo / teaser，重点展示“编译器先把自己编出来”这件事；生成结果目前是 ARM64 Linux 定向版本；作者已经用这套方案让 Rust 程序跨机器、甚至跨网络去驱动目标侧 C 编译器，还举了在 Plan 9 目标上跑通小程序的例子。对“Rust 是否只能活在 LLVM 支持良好的现代平台”这个老问题来说，这个项目等于抛出了一个相当硬核的新回答。

项目仓库：https://github.com/FractalFir/crustc 相关背景：https://github.com/FractalFir/crustc

原文链接：https://github.com/FractalFir/crustc

Anthropic 的 buffa 库曝出内存放大 DoS：64 MiB 输入最高可打到约 1.4 GB 堆占用

这条安全向内容的传播点很明确：被点名的是 Anthropic 的 Rust protobuf 库 buffa，而且问题不是传统内存越界，而是 memory-safe 代码里的分配预算失控。文章里复盘说，Endor Labs 的 AI SAST 先顺着 unknown-field 解码路径，找到一个按攻击者控制长度直接分配 Vec<u8> 的 sink；继续深挖后，又定位到 StartGroup 分支里更危险的放大路径：攻击者可以用极小的嵌套字段编码，把输入逐步膨胀成大量 UnknownField 结构分配。

最容易被转发的，是它给出了相当具体的量级：在 64 位平台上，一个最便宜的嵌套字段只要 2 字节线缆输入，却能在堆上对应到大约 40 字节结构开销；实测里，64 MiB 的特制 payload 最终能把解码过程推到 约 1.41 GB 的峰值内存，占到大约 22 倍放大。在设置了 256 MiB cgroup 限制的 Docker 场景里，服务会直接被 OOMKilled（137）。

受影响范围也比较清楚：使用默认 preserve_unknown_fields=true 生成代码的 buffa / connectrpc Rust 包，0.8.0 之前版本存在风险；修复版已经在 0.8.0 落地，方案是给 unknown field 数量加上 per-message 限制，用户如果暂时没法升级，也可以通过重新生成代码并关闭 unknown-field 保留路径来规避。对 Rust 社区来说，这类案例很有提醒意义：内存安全不等于资源安全，而“输入大小有限”也不天然等于“堆分配上界有限”。

原文：https://www.endorlabs.com/learn/endor-labs-ai-sast-finds-zero-day-cve-2026-55407-buffa 安全通告：https://github.com/anthropics/buffa/security/advisories/GHSA-f9qc-qg88-7pq5 项目仓库：https://github.com/anthropics/buffa

原文链接：https://www.endorlabs.com/learn/endor-labs-ai-sast-finds-zero-day-cve-2026-55407-buffa

tokio 管 I/O、rayon 管 CPU：Rust 搜索引擎把两套并发模型桥接到一起

这篇来自 infino 的工程帖有一个很典型、但很多团队都会踩坑的主题：在 Rust 服务里，I/O 密集 和 CPU 密集 工作到底该怎么分层，尤其是当你同时用 tokio 和 rayon 的时候。作者讲得很细：查询某个 supertable 时，打开 object storage 上的 superfile、发 S3/Azure range GET、预取 tombstone sidecar 这些都是 I/O，所以交给 tokio；但真正去解码 Parquet page、算 BM25、跑向量距离、做 rerank，这些是同步且吃核的 CPU 工作，就交给 rayon 的线程池。

真正有价值的是它没有停在“tokio 负责 async、rayon 负责并行”这种口号层，而是把桥接手法讲出来了：async 任务不能直接在 tokio worker 上内联跑 par_iter()，否则会把 runtime worker 卡死，于是他们把 CPU 闭包扔给 rayon，再用 tokio::sync::oneshot 把结果桥回 async 侧；反过来，当同步 API、rayon 线程、CLI 或 Python 绑定需要掉进 async 存储层做 I/O 时，又专门做了一个 runtime_bridge 去决定何时 block_in_place + Handle::block_on、何时新建 current_thread runtime。

更有意思的是，作者还复盘了一个“曾经以为更省，结果 benchmark 打脸”的地方：他们一度把 sync→async 入口统一路由进一个共享的 multi_thread().worker_threads(1) runtime，理论上觉得复用 runtime 比每次建一个更便宜，结果在多词全文检索场景里反而带来了 6%–17% 的性能回退，最后重新切回 current_thread 才修回来。对于正在做数据库、检索或高并发服务的 Rust 团队来说，这种把抽象层、线程池和实测基准一起摊开的经验帖，实用价值很高。

原帖：https://old.reddit.com/r/rust/comments/1ulo7pr/tokio_for_io_rayon_for_cpu_how_we_bridge_them_in/ 项目仓库：https://github.com/infino-ai/infino

原文链接：https://old.reddit.com/r/rust/comments/1ulo7pr/tokio_for_io_rayon_for_cpu_how_we_bridge_them_in/

一次真实的 rustc 误编译：bool as u32 让分支消失，修复 PR 18 小时内落地

“不是我写错了，是编译器错了”这句话，平时大多是程序员嘴硬，但这次作者真的抓到了一次 rustc 误编译。触发条件甚至很普通：原本的 parser 代码是 if cond { self.consume(); true } else { false }，作者为了让生成汇编更紧凑，把它改写成 let x = self.peek(store) == expected; self.0 += x as u32; x。按语言语义，这个改写完全成立；但放进真实的 for-loop 解析路径后，程序却开始错误地报 parse error。

作者后面做的排查过程非常适合传播：先怀疑自己是不是记错了 bool as u32 的行为，再把表达式改成更显式的 if x { 1 } else { 0 }，发现后一版又一切正常；再往下翻汇编，直接看到关键的 INC 指令像被编译器“吃掉了”。继续缩小问题后，作者用 -Cno-prepopulate-passes 和 -Zmir-opt-level=0 去分辨是 LLVM 优化层还是更前面的 Rust 编译流程出了问题，最终确认这是一次真正的 miscompile，并提交了最小复现。

更值得记一笔的是社区响应速度：问题被打上 p-critical 和 i-miscompile 标签，而修复 PR 在 18 小时内 就已经打开并推进。对 Rust 生态来说，这条内容的价值不只是“抓到一个编译器 bug”，而是它展示了：即使是最危险的一类 safe-code 误编译问题，社区和核心维护者的响应链路也依然很快。

原文：https://parsa.wtf/cast/ 问题链接：https://github.com/rust-lang/rust/issues/158206 修复 PR：https://github.com/rust-lang/rust/pull/158214

原文链接：https://parsa.wtf/cast/