本文是来自 The University of Manchester 的 John Alistair Kressel 等发表在 ACM SOSP 2025 上的论文。

µFork成功解决了在单地址空间操作系统中支持POSIX fork的长期难题。通过巧妙利用CHERI硬件特性和创新的CoPA优化策略，µFork在保持SASOS轻量化特性的同时，提供了强隔离性和完全的应用兼容性。

Abstract:

Single-address-space operating systems have well-known lightweightness benefits that result from their central design idea: the kernel and applications share a unique address space. This model makes these operating systems (OSes) incompatible by design with a large class of software: multiprocess POSIX applications. Indeed, the semantics of the primitive used to create POSIX processes, fork, are inextricably tied to the existence of multiple address spaces. Prior approaches addressing this issue trade off lightweightness, compatibility and/or isolation. We propose μFork, a single-address-space operating system design supporting POSIX fork on modern hardware without compromising on any of these key objectives. μFork emulates POSIX processes (μprocesses) and achieves fork by creating for the child a copy of the parent μprocess’ memory at a different location within a single address space. This approach presents two challenges: relocating the child’s absolute memory references (pointers), as well as providing user/kernel and μprocesses isolation without impacting lightweightness. We address them using CHERI. We implement μFork and evaluate it upon three real-world use-cases: Redis snapshots, Nginx multi-worker deployments, and Zygote FaaS worker warm-up. μFork outperforms previous work and traditional monolithic OSes on key lightweightness metrics by an order of magnitude, e.g. it can offer a fork-bound FaaS function throughput 24% higher than that of a monolithic OS, and can fork a μprocess in 54 μs, 3.7× faster than a traditional fork.

Entry：Zotero link URL link

Background

单地址空间操作系统（Single-Address-Space Operating Systems, SASOS）是一种将内核和所有用户程序共置于单一地址空间的操作系统设计。这种设计带来了显著的轻量化优势：

• 性能提升: 通过优化的上下文切换和快速的安全域转换
• 低内存占用: 减少内存开销
• 快速进程间通信（IPC）: 消除地址空间切换的开销
• 快速I/O操作: 简化I/O处理流程

SASOS在云计算、边缘计算和机密计算等领域越来越受欢迎，但面临一个关键障碍：缺乏对多进程POSIX应用程序的支持。

Motivation

POSIX的fork系统调用是创建新进程的主要机制，其语义与多地址空间密不可分。然而，真正的SASOS只能有一个地址空间，这使得fork在SASOS中实现变得极其困难。

现有解决方案的局限性：

• 早期SASOS使用段相对寻址，但现代工具链支持不足
• 某些方案放弃隔离性，带来安全风险
• 其他方案通过虚拟化重新引入多地址空间，牺牲轻量化特性
• 手动移植应用程序避免调用fork，工程成本巨大

CHERI（Capability Hardware Enhanced RISC Instructions）

CHERI是一种硬件安全技术，通过以下方式增强RISC指令集：

• 能力指针: 将64位指针扩展为128位，包含边界和访问权限信息
• 内存标记: 每个指针都有不可伪造的有效性标记
• 硬件隔离: 在单一地址空间内提供进程间隔离

µFork提出了Copy-on-Pointer-Access (CoPA)内存复制优化策略：

• 触发条件: 当父进程或子进程写入内存，或子进程加载绝对内存引用时
• 优化原理: 只在必要时复制页面，减少不必要的内存复制
• 实现方式: 使用CHERI的页面权限位检测能力加载

主要贡献：

1. 首次在单地址空间内实现完整的POSIX fork语义
2. 提出创新的内存引用重定位和进程隔离机制
3. 开发CoPA等优化策略，显著提升性能
4. 通过实际应用验证了方案的可行性和优势

Design

Overview

µFork提出了一个创新的解决方案，在单一地址空间内模拟POSIX进程（称为µprocesses），通过以下方式实现fork：

1. 内存复制: 将父进程的内存复制到同一地址空间内的不同位置
2. 内存引用重定位: 识别并重定位子进程中的绝对内存引用（指针）
3. 进程隔离: 在单一地址空间内提供强隔离

Challenges

挑战1: 内存引用重定位（C1）

• 需要识别子进程中指向父进程内存区域的绝对内存引用
• 将这些引用重定位到子进程的正确位置
• 确保隔离性和等价行为

挑战2: 进程隔离（C2）

• 在单一地址空间内隔离µprocesses
• 在µprocesses和内核之间提供隔离
• 保持轻量化特性

Solution

利用CHERI技术：

• 内存标记: 使用CHERI的标记功能识别和重定位绝对内存引用
• 硬件能力: 利用CHERI的硬件能力实现地址空间内隔离
• 位置无关代码（PIC）: 编译为PIC以限制需要重定位的引用数量

Copy-on-Pointer-Access (CoPA)：

• 传统Copy-on-Write的优化版本
• 当子进程访问包含指针的页面时触发复制
• 比传统CoW和Copy-on-Access更高效

Evaluation

性能优势

fork延迟：

• µFork可以在54微秒内fork一个µprocess
• 比传统FreeBSD fork快3.7倍
• 比Nephele的VM方法快198倍

内存消耗：

• 比CheriBSD减少2.2倍内存使用
• 比Nephele减少12.3倍内存使用

FaaS性能：

• 在fork绑定的FaaS函数吞吐量上比传统OS高24%

实际应用验证

Redis快照：

• 在100KB到100MB数据库大小范围内，µFork始终优于CheriBSD
• 在100KB时快1.9倍（1.8ms vs 3.4ms）
• 在100MB时快1.4倍（109ms vs 158ms）

Nginx多工作进程：

• 成功支持Nginx的多工作进程部署
• 保持高并发处理能力

MicroPython FaaS：

• 在1-3核心配置下，µFork处理24%更多的请求
• 显著改善冷启动时间

CoPA优化效果

• 相比同步复制，CoPA可将fork延迟降低89倍
• 相比CoA，CoPA可降低1.18倍延迟
• TOCTTOU保护的成本相对较小（在100MB时为2.6%）

Pro/Cons

• Pro
  • 技术优势：
    • 真正保持单地址空间的轻量化特性
    • 提供强隔离性，满足安全要求
    • 对应用程序完全透明，无需修改
    • 性能显著优于现有方案
  • 实用性：
    • 支持真实世界的fork使用场景
    • 可集成到现有SASOS中
    • 提供参数化隔离，适应不同威胁模型
  • 创新性：
    • 首次在单地址空间内实现完整的POSIX fork语义
    • 巧妙利用现代硬件安全特性
    • 提出CoPA等优化策略
• Con
  • 硬件依赖：
    • 需要CHERI硬件支持，限制了部署范围
    • 目前只能在ARM Morello等特定平台上运行
  • 实现复杂性：
    • 需要大量工程工作来移植到现有SASOS
    • 需要修改编译器工具链以支持CHERI
  • 性能开销：
    • CHERI能力检查可能带来一定性能开销
    • 内存标记和重定位过程需要额外计算
  • 兼容性：
    • 依赖位置无关代码（PIC）
    • 某些遗留代码可能需要修改

Last modified on 2025-10-01