系统与数据库2017arxiv.org
迈向 Linux 内核内存安全
Towards Linux Kernel Memory Safety
专业 · 约 90 分钟读完前置知识：操作系统内核基础、C 语言内存管理、并发与原子操作
导读
这篇论文探讨了如何在 Linux 内核中实现内存安全，提出了包括基于引用计数（refcount）的溢出保护以及利用 Intel MPX 硬件特性检测内存错误等在内的多种技术路径，以缓解内核中缓冲区溢出、释放后使用等内存安全问题。
HN 关注点：Linux 内核的内存安全漏洞长期是安全研究热点，HN 读者关注论文提出的具体机制（如 refcount 实现、MPX）在真实内核中的可行性与性能代价。
HN 评论精选
这几条评论里：质疑 2 补充 2
质疑质疑论文 refcount 采用 CAS 而非常规原子递增的设计选择
给感兴趣的人附上源码链接：https://github.com/torvalds/linux/blob/master/lib/refcount.c。我有点惊讶作者在引用计数上选择了 compare-and-exchange 而不是 get-and-increment。即使计数器溢出，通常也是可检测且可恢复的，即使存在并发更新也是如此。好处是快速路径上只有一次原子操作。
anameaname查看英文原文
Source for those interested: https://github.com/torvalds/linux/blob/master/lib/refcount.c I'm kind of surprised that the authors went with compare-and-exchange for their ref count, rather than get-and-increment. Even if the counter does overflow, it's usually detectable, and reversible. This is true even in the face of concurrent updates. The benefit is that there is only one atomic operation in the fast path.
补充补充 MPX 生态现状：编译器支持萎缩、AMD 缺席，前景堪忧
论文的 MPX 部分让我顺便了解了 MPX 支持的现状。看起来 GCC 是支持它的主要编译器，但由于 MPX 自举构建坏了很久，该支持面临被弃用的威胁。另外 AMD 不买账（专利原因？）相比 SoftBound、CCured 等更兼容的基于编译器的 C 内存安全方案，似乎是很大的阻碍。
fulafel查看英文原文
The MPX part was a good excuse to look around at the status of MPX support. It seems GCC is the major compiler to support it, but it's under threat of depreciation because the bootsrap build with MPX has been broken for so long. Also the lack of AMD buy-in (patents?) seems like a big hinderance compared to more compatible compiler-based approaches for C memory safety, like SoftBound, CCured, etc.
补充认为根本出路是用内存安全语言重写操作系统
长期来看，解决方案必须是切换到用内存安全语言编写的操作系统。
empath75查看英文原文
Long term, the solution has to be switching to an OS that’s written in a memory safe language.
质疑质疑 MPX 在多线程下的竞态问题是否会阻碍部署
有人能评论一下 MPX 中的竞态问题吗？这会不会阻碍它的实际部署？https://intel-mpx.github.io/microbenchmarks/#multithreading
DSingularity查看英文原文
Can anyone here comment on the races in MPX and whether this will prevent deployment? https://intel-mpx.github.io/microbenchmarks/#multithreading
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2017Hacker News 讨论帖144 分 · 95 评
同领域还值得读
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 分钟编辑精选