【操作系统百科】FreeBSD 与 OpenBSD 的不同选择

FreeBSD 与 OpenBSD 都源自 386BSD（1992），但两者的设计哲学早已分道扬镳。本文不是”列举差异”的速查表，而是解释这些差异背后的工程取舍：为什么 OpenBSD 坚持拿掉蓝牙支持？为什么 FreeBSD 把 ZFS 做进内核？为什么两个项目的 pf 现在已经是不同的代码？以及，分别应该在什么场景下选哪一个。

flowchart TD
    4.4BSD[4.4BSD-Lite<br/>1994] --> 386BSD[386BSD<br/>1992]
    386BSD --> FREE[FreeBSD<br/>1993]
    386BSD --> NET[NetBSD<br/>1993]
    NET --> OPEN[OpenBSD<br/>1995 fork from NetBSD 1.0]

    FREE --> ZFS[通用高性能 OS<br/>ZFS / jail / bhyve / Capsicum]
    OPEN --> PLEDGE[安全优先 OS<br/>pledge / unveil / pf / W^X]

    classDef root fill:#76839022,stroke:#768390,color:#adbac7;
    classDef free fill:#388bfd22,stroke:#388bfd,color:#adbac7;
    classDef open fill:#f0883e22,stroke:#f0883e,color:#adbac7;
    class 4.4BSD,386BSD root
    class FREE,ZFS free
    class NET,OPEN,PLEDGE open

上图的关键信息：OpenBSD 是 1995 年从 NetBSD 1.0 fork 出来的，不是从 FreeBSD 分出来的。两个项目的共同祖先要追溯到 386BSD 和 4.4BSD-Lite。搞清楚这一点，才能理解为什么 FreeBSD 和 OpenBSD 在一些内核子系统上的实现走向完全不同——它们各自独立演化了近 30 年。

一、两条相反的路径

一句话概括两个项目的分叉点：

• FreeBSD 追求”做最好的通用 Unix”——高性能、广泛硬件支持、ZFS 存储、jail 容器、二进制兼容 Linux 程序，是 Netflix CDN、Sony PlayStation、WhatsApp 的基础设施底座。
• OpenBSD 追求”做最安全的 OS”——代码正确性高于一切，默认安装只开了两个远程漏洞（在整 30 年历史中有记录），所有子系统都围绕”减少攻击面”设计。

这个选择决定了几乎所有下游差异：FreeBSD 愿意为性能引入复杂度（内核 TLS 卸载、NUMA 感知、多队列网卡驱动），OpenBSD 愿意为安全砍掉功能（去掉蓝牙、禁止内核模块加载、弱化多线程性能）。

二、安全模型：pledge/unveil vs Capsicum/jail

两个项目都做了进程沙箱，但思路完全不同。

2.1 OpenBSD：进程自限

OpenBSD 的安全哲学是”程序应该自己声明它需要什么权限，而不是靠外部配置限制”。两个核心系统调用：

// 进程启动后立即限制自己能调的系统调用
pledge("stdio rpath inet", NULL);

// 限制能访问的文件系统路径
unveil("/var/www", "r");
unveil("/etc/ssl", "r");
unveil(NULL, NULL);  // 锁定，之后不能再 unveil

pledge(2) 在 OpenBSD 5.9（2016）引入，将 370+ 个系统调用按语义分成 20+ 个 promise 组（stdio、rpath、wpath、inet、dns、proc、exec 等），进程启动后只需声明自己需要哪些组。内核会在 syscall 入口处检查是否在 pledge 范围内，不在就直接 SIGABRT。

unveil(2) 在 OpenBSD 6.4（2018）引入，类似”文件系统白名单”，进程只能访问显式 unveil 过的路径。和 pledge 配合后，一个被攻破的守护进程几乎什么也做不了。

这两个系统调用的设计代价是侵入性——每个要沙箱的程序都得在源码里加 pledge/unveil 调用。OpenBSD 的做法是，把整个 base 系统（httpd、relayd、ntpd、smtpd、acme-client、unbound 等）全部 pledge/unveil 化。效果是：即使某个守护进程有 RCE 漏洞，攻击者拿到的也是一个几乎不能做任何事的受限进程。

此外，OpenBSD 还有以下全局安全机制：

• W^X（Write XOR Execute）：内存页不能同时可写可执行。这是通过严格的内存映射策略在默认内核中强制实施的，不存在”关闭 W^X”的选项。
• KARL（Kernel Address Randomized Link）：每次启动或升级时重新链接内核，使得内核基址和函数偏移在每台机器上都不同。
• SROP 缓解：通过 sigreturn(2) 的内核侧检查防止 Sigreturn-Oriented Programming。
• 内核锁细化：OpenBSD 内核一直以”全局大锁”著称，但从 6.x 到 7.x 一直在渐进细化锁粒度，同时保证 correctness 优先于性能。

2.2 FreeBSD：能力模式与 jail

FreeBSD 的安全策略更像”渐进式加固”：

Capsicum（FreeBSD 9.0，2012）走的是 capability 路线：进程进入 capability mode 后失去对全局命名空间（文件系统路径、PID 空间）的访问，只能通过已持有的文件描述符操作。

cap_enter();  // 进入 capability mode
// 之后不能 open()、不能 stat()，只能用已持有的 fd
read(fd, buf, size);  // 仍然可用

Capsicum 比 pledge 更早出现，设计更”干净”（不区分 promise 类别，一刀切地禁止全局命名空间），但因此也更难嵌入现有程序——几乎要求程序以 fd 为中心重写架构。

jail（FreeBSD 4.0，2000）是 Linux namespace 的真正的老祖宗：把一个进程及其子进程隔离到自己的 IP、主机名、文件系统根、进程空间里。与 Linux namespace 的”按维度组合”不同，jail 是一体化隔离——创建即完成所有维度的隔离。

# 创建 jail
jail -c name=websrv path=/jail/web host.hostname=web ip4.addr=10.0.0.10 \
     allow.raw_sockets=0 enforce_statfs=1

jail 的优势是简单——一条命令创建完全隔离的环境，不需要像 Linux 那样组合 6-7 个 namespace 加 cgroup。代价是灵活性较低：没办法”只要网络隔离不要文件系统隔离”，因为 jail 的设计就是全有或全无。

FreeBSD 的安全加固通常需要手动配置：ASLR 需要显式开启，security.bsd.see_other_uids 用于隐藏其他用户的进程，kern.elf64.aslr.stack_gap 等 sysctl 可调节。

2.3 对比

OpenBSD 的项目宣言里直接写了”[to be] NUMBER ONE in the industry for security”，这个目标真实地驱动了几乎所有架构决策。

三、文件系统：ZFS 一等公民 vs FFS2

这是两个 BSD 最明显的分岔点之一。

3.1 FreeBSD 与 ZFS

FreeBSD 从 8.0（2009）开始把 ZFS 做进内核，至今已持续投入超过 15 年。FreeBSD 上的 ZFS 基于 OpenZFS（和 Linux 上的 openzfs 同源，来自 illumos 那支），不是第二等公民——boot environment、root-on-ZFS、ZFS 快照启动菜单都是原生支持的。

# FreeBSD 上创建 ZFS boot environment
bectl create post-upgrade
bectl activate post-upgrade
# 升级失败？重启，从引导菜单选旧 environment 回滚

这解决了运维中最脆弱的一环：系统更新不可回滚。Linux 上要达成同等效果需要搭配 LVM 快照或者额外的工具链。

ZFS 带来的能力包括：快照（zfs snapshot）、克隆、压缩（lz4/zstd）、去重、自愈式校验（checksum on every block）、RAID-Z（比传统 RAID5/6 更可靠）、send/recv（增量复制）。

FreeBSD 内核和 ZFS 的集成深度还在持续扩展：14.x 中已将 OpenZFS 更新到 2.2.x 分支，支持 block cloning（reflink 的 ZFS 等效）等新特性。

3.2 OpenBSD 与 FFS2

OpenBSD 默认使用 FFS2（Fast File System v2），这是一个成熟的 BSD 原生文件系统，源自 4.4BSD-Lite。FFS2 支持 64-bit 块号（最大文件系统和文件大小远超 FFS1），支持 softdep（延迟写元数据以提升性能），但功能和 ZFS 不在一个量级：没有快照、没有内置压缩、没有 checksum、没有 RAID。

OpenBSD 社区对 ZFS 的立场是明确的不引入。Theo de Raadt 在多次邮件列表讨论中表达的理由包括：

• CDDL 许可证与 OpenBSD 的 ISC 政策冲突（虽然这不是唯一原因，FreeBSD 同样面临 CDDL，但选择接受）
• ZFS 代码量大且复杂，与 OpenBSD”代码必须能被少数人审计”的原则冲突
• ZFS 的内存消耗不适合 OpenBSD 定位的防火墙/嵌入式/小型设备场景

OpenBSD 提供了 softraid(4) 做软件 RAID（RAID 0/1/5/CRYPTO），但它的定位不是 ZFS 的替代品，而是一个轻量的磁盘冗余层。

3.3 其他文件系统支持

FreeBSD 还支持 UFS2（FFS 的继承者）、tmpfs、msdosfs、NFSv4、FUSE（包括 squashfuse、sshfs 等用户态文件系统）。

OpenBSD 支持 FFS2、tmpfs、msdosfs（只读）、NFS（v2/v3）、以及通过 vnd(4) 挂载磁盘镜像。

四、网络栈与防火墙

4.1 pf 的分裂

两个项目都使用 pf（packet filter）作为防火墙，但它们已经是两个不同的 pf：

• OpenBSD pf：2001 年 Daniel Hartmeier 在 OpenBSD 上原创。语法简洁，规则原子性提交，自 4.7（2010）以来持续演进（queuing、divert-to、syncookies、AF-to 等）。
• FreeBSD pf：2004 年从 OpenBSD 3.5 移植过来。之后独立演进，由于 FreeBSD 内核锁机制不同，FreeBSD pf 从 10.0 开始做了大量多核并行化改造。FreeBSD 15.0 正在重新同步部分 OpenBSD pf 语法（nat-to、rdr-to、match 等规则类型），但目前 FreeBSD 14.x 的 pf 语法仍和 OpenBSD 有显著差距。

FreeBSD 额外提供了 ipfw 和 ipfilter 作为备选防火墙，但社区推荐的方向是 pf。

OpenBSD pf 是 OpenBSD 网络生态的核心：relayd（七层负载均衡）、iked（IKEv2 VPN）、vmd（虚拟机管理器）的网络平面、甚至 veb(4)（虚拟以太网桥）都深度依赖 pf 做包处理。

4.2 网络性能

这是 FreeBSD 明显领先的领域。以下是基于公开部署数据和技术报告的对比：

OpenBSD 的网络栈优化原则是：正确性 > 性能。如果优化会引入 corner case 或安全隐患，宁可不做。这让 OpenBSD 在防火墙/VPN 路由器场景中稳定可靠，但在高吞吐 CDN/存储场景中不如 FreeBSD。

一个具体的例子：2025 年底 University of Toronto 系统管理团队把防火墙从 OpenBSD 迁移到 FreeBSD，直接原因是 10G 线速下 OpenBSD 需要大量调优才能稳定跑满，而 FreeBSD “在更少调优下就有明显更好的 10G 性能”。迁移的附带收益是 ZFS root 可以做系统升级快照回滚（OpenBSD 没有等价机制）。

4.3 其他网络能力

FreeBSD 独有的网络特性：

• netmap：高性能用户态包 I/O 框架，零拷贝绕过内核网络栈
• VALE：基于 netmap 的虚拟交换机
• bhyve 虚拟交换机：用于虚拟机网络隔离
• LinuxKPI 网卡驱动层：复用部分 Linux 网卡驱动代码

OpenBSD 独有的网络特性：

• vmd(8)：轻量级虚拟机管理器，内置于 base 系统
• veb(4)：虚拟以太网桥
• switch(4)：虚拟交换机（配合 vmd 使用）
• 完整的 IPSec/IKEv2 栈：iked + ipsec.conf，base 系统内置

五、虚拟化与容器

FreeBSD 的 jail 是它最被低估的特性之一。Docker 的早期版本甚至借鉴了 jail 的设计思路。今天的 jail 已经支持了：VNET（每个 jail 独立的网络栈）、ZFS 数据集挂载、资源限制（rctl）、jail.conf 声明式配置。

OpenBSD 的 vmm/vmd 只支持运行 OpenBSD 客户机，这是有意为之——不支持运行其他 OS，意味着不需要维护跨 OS 的虚拟设备仿真层，大大缩小了代码量和攻击面。vmd 的整个代码量不到两万行，bhyve（FreeBSD）则大得多（支持 NVMe、VirtIO、AHCI、e1000 等多种设备模拟）。

六、包管理与软件生态

FreeBSD 的 Ports Collection 是它最大的生态资产之一——36,000+ 的应用和库，覆盖从数据库（PostgreSQL/MySQL）到语言运行时（Go/Rust/Python/Node.js）到容器编排（Nomad/K3s）的全部领域。

OpenBSD 的 ports 策略是”少但审慎”：每个 port 必须能编译、必须经过安全审查、必须遵守许可证政策。这意味着 TensorFlow 这种重度依赖 blob/复杂依赖链的包在 OpenBSD 上不可用，但在 FreeBSD 上可用。这不是缺陷，是 OpenBSD 的明确取舍。

OpenBSD base 系统自带了大量通常需要额外安装的组件：

• httpd(8)：内置 Web 服务器（支持 FastCGI 和 TLS）
• acme-client(1)：ACME 客户端（Let’s Encrypt 证书自动签发）
• relayd(8)：七层负载均衡和 TLS 终结
• smtpd(8)：SMTP 邮件服务器
• nsd(8) / unbound(8)：权威 DNS + 递归 DNS
• ntpd(8)：极简 NTP 客户端（安全优先，精度牺牲）
• iked(8)：IKEv2 VPN 守护进程

在 OpenBSD 上搭一个完整的 Web 服务栈只需要 base 系统，不需要装任何包。FreeBSD 则更多依赖第三方包。

七、社区与治理

两个项目的组织方式正好是”基金会模式”与”个人领导模式”的对立。

7.1 FreeBSD

FreeBSD 由一个选举产生的 Core Team（9 人）和 FreeBSD Foundation（非营利组织）共同治理。Core Team 负责技术方向，Foundation 负责资金、法务和在用、开发者峰会。

规模（基于 2025 Q1 状态报告）：

• Commit 权限开发者：ports 方面有 158 名活跃 committer（Q1 2025 数据），估计 src + ports + doc 三棵树的开发者总数在 350-400+
• FreeBSD Foundation 2024 年收入：$1,524,259
• 全职员工 7 人 + 合同工 19 人
• Discord 社区：5,300+ 成员，3,000+ 月活跃
• Google Summer of Code：连续 21 年参与
• 代码仓库：2020 年底从 Subversion 迁移到 Git，托管在 git.FreeBSD.org

FreeBSD 决策偏社区共识，发布周期稳定（每年 1-2 个大版本），文档和社区指南比较完善（Code of Conduct 引入较早）。

7.2 OpenBSD

OpenBSD 的治理结构是 Theo de Raadt 的单一领导 + 开发者团队。没有 formal core team，没有非营利基金会（OpenBSD Foundation 是加拿大的非营利实体，但只做资金托管，不参与治理）。

规模：

• 活跃 committer：约 80-100 人（比 FreeBSD 小一个量级）
• 项目资金主要来自捐赠（通过 OpenBSD Foundation）
• 无全职员工：开发者以志愿者或由雇主资助时间
• 代码仓库：CVS（至今未迁移到 Git）。所有 commit 信息公开可查，Web 界面（cvsweb）暴露全部历史和 diff

OpenBSD 的治理是”code talks”——提交权限授予凭代码质量，不凭社区活跃度或政治考量。Theo de Raadt 拥有最终决定权，但他的否决通常基于强烈的技术判断而非个人偏好。

这种模式导致了两个显著特征：

• 效率极高：没有委员会，没有 RFC 流程，技术决策直达
• 社区风格尖锐：邮件列表上对低质量代码和思路的批评不留情面。这不是”toxic”，而是”对技术标准毫不妥协”带来的筛选效应

7.3 社区对比

八、文档

BSD 世界的文档质量整体远超 Linux 生态，但两个项目的文档风格差异很大。

FreeBSD Handbook 是一本从安装到运维的完整操作手册，章节涵盖安装、桌面、网络、安全、虚拟化、存储，适合从零开始学习的读者。FreeBSD man page 也保持了 BSD 的质量传统，且 Handbook 与 man page 互相引用的习惯很强。

OpenBSD 的 man page 是业内公认质量最高的文档之一。每个系统调用的 BUGS 节会诚实地列出已知问题（包括”这个实现目前不完整”或”多线程下有竞争”）。OpenBSD FAQ 覆盖安装、包管理、防火墙配置、磁盘设置，但假设读者具备一定的 Unix 基础，不会从”什么是 shell”讲起。

一个典型对比：FreeBSD 的 jail 文档解释”怎么用”，OpenBSD 的 pledge(2) man page 除了”怎么用”还详细列出每个 promise 的内核实现细节。

九、硬件支持与驱动

FreeBSD 的硬件支持明显更广：

• CPU 架构：amd64、arm64、i386、powerpc64、riscv64
• 网卡：Intel（ixgbe/ice/igb）、Mellanox（mlx5）、Chelsio（cxgbe）、Broadcom（bnxt）、Realtek 等广泛支持
• GPU：Intel i915/kms、AMD amdgpu 有持续更新
• 存储：NVMe、SAS/SATA、HBA（LSI/Broadcom/PMC）

FreeBSD 还通过 LinuxKPI 兼容层复用了部分 Linux 驱动代码（主要是 GPU/无线网卡方向），这是项目近年来最务实的决策之一。

OpenBSD 的硬件支持策略更为保守：

• CPU 架构：amd64、arm64、i386、armv7、octeon、powerpc64、riscv64
• 禁止驱动中包含闭源固件 blob ——这意味着很多现代无线网卡、部分 GPU、部分 RAID 控制器在 OpenBSD 上不可用
• 默认禁用 Hyper-Threading（安全原因：Spectre/Meltdown 类的侧信道攻击不需要 root 权限即可跨 HT 泄露数据）
• 在老旧硬件上的兼容性往往更好——社区报告显示 OpenBSD 7.5 在 ThinkPad T400/X200（2008 年机型）上”直接可用”，而 FreeBSD 14.2 在这些机器上有启动问题

OpenBSD 的驱动策略是一个经典的 trade-off：丢掉一些硬件，换来驱动代码更小、更可审计、更安全。

十、发布模型

OpenBSD 的 sysupgrade 特别值得一提——它会在升级前自动验证签名（signify），下载新版本的 sets，reboot 后自动完成安装。整个过程不超过 10 分钟。这是 OpenBSD”安全优先，自动化一切”哲学的体现。

FreeBSD 的升级流程相对传统：freebsd-update 处理二进制补丁，或通过 git pull && make buildworld 从源码升级。freebsd-update 不如 sysupgrade 简洁，但更适合生产环境中需要控制升级窗口、分批滚动的场景。

十一、生产案例

FreeBSD

OpenBSD

OpenBSD 的生产案例很少公开发表（这是安全界的惯例——用了别张扬），但可以从 ports 树的维护状态、邮件列表中的问题类型、以及 pf 相关的技术讨论中间接推断至少有数百个组织在生产环境使用 OpenBSD。

十二、选型框架

选 FreeBSD 的场景

选 OpenBSD 的场景

两个都不该选的场景

• 你需要运行 Docker/Kubernetes：BSD 没有 cgroup/namespace 体系，也不会有。Docker 是 Linux 专属。用 FreeBSD jail 可以替代部分容器场景，但不能替代 K8s 生态。
• 你的应用只支持 Linux：比如 Deep Learning 训练（CUDA）、大部分闭源企业软件（Oracle DB、SAP）、最新的 GPU 驱动（NVIDIA consumer card 的 BSD 驱动几乎不存在）。
• 你需要商业支持合同：Linux 有 Red Hat/Canonical/SUSE；FreeBSD 通过 Foundation 有一些商业支持渠道，OpenBSD 几乎没有。
• 团队里没有 BSD 经验且有交付压力：BSD 的学习曲线不如”直接用 Ubuntu”平坦。着急交付的前提下，选择团队已经会用的 OS。

两边都用

实践中不罕见：OpenBSD 做防火墙/边缘，FreeBSD 做存储/后端。两者的 pf 规则可以互相迁移（需要注意语法差异），管理工具（sh、syslogd、cron）高度一致，迁移成本较低。

十三、值得注意的交叉影响

两个项目虽然独立演进，但存在持续的交叉影响：

• OpenBSD 原创的 pf → FreeBSD 2004 年移植，现成 FreeBSD 主力防火墙
• OpenBSD 原创的 OpenSSH → 两个项目都内置，全世界都在用
• OpenBSD 原创的 relayd → FreeBSD ports 中有
• OpenBSD 原创的 signify → FreeBSD 13.0 纳入 base 系统
• OpenBSD 的 pledge/unveil 理念 → FreeBSD 社区有讨论，但未被采纳（Capsicum 是不同路径）
• FreeBSD 原创的 jail → Linux namespace 的精神先驱
• FreeBSD 对 pf 的 多核并行化 → OpenBSD 关注但未移植（锁模型不同）

OpenSSH 是最有代表性的案例：它是 OpenBSD 项目孵化的，现在几乎所有 Unix/Linux 都在用，但 OpenBSD 团队从未试图通过 OpenSSH 商业化或施加许可约束——完全符合项目最初的 ISC/BSD 自由许可理念。

十四、总结

FreeBSD 和 OpenBSD 的分岔根植于对同一个问题的不同答案：操作系统的正确性到底应该在哪个维度衡量？

OpenBSD 的答案是安全——代码少即正确，没人审计过的代码就是有风险的代码。FreeBSD 的答案是功用——能跑的生产负载多即正确，性能差的功能等于没有。

这两个答案都是合理的。它们指向不同的工程优先级，造就了两种完全不同的 BSD 体验。理解这一点比记住任何具体的技术差异都重要——因为所有具体差异（ZFS vs FFS2、pledge vs Capsicum、CVS vs Git、~100 vs ~400 开发者）都是这两个根本答案的推导结果。

参考文献

规范与官方文档

• FreeBSD Handbook, FreeBSD Documentation Project
• OpenBSD FAQ, The OpenBSD Project
• OpenBSD pledge(2), unveil(2), jail(8), capsicum(4) man pages
• FreeBSD jail(8), bhyve(8), zfs(8), capsicum(4) man pages
• FreeBSD Project. “Q1 2025 Status Report”, freebsd.org

书籍

• McKusick, M. K., Neville-Neil, G. V., Watson, R. N. M. The Design and Implementation of the FreeBSD Operating System, 2nd ed. Addison-Wesley, 2014
• Lucas, M. W. Absolute FreeBSD, 3rd ed. No Starch Press, 2018
• Lucas, M. W. Absolute OpenBSD, 2nd ed. No Starch Press, 2013

论文与演讲

• Gallatin, D. “Serving 100 Gbps from an Open Connect Appliance”, Netflix Tech Blog, 2021
• Gallatin, D. et al. “Serving Netflix Video Traffic at 400Gb/s and Beyond”, EuroBSDCon / Kaltura, 2022
• Looney, J. “Netflix and FreeBSD”, FOSDEM 2019
• de Raadt, T. “Exploit Mitigation Techniques”, OpenBSD hackathon presentations, 2005-2023

社区讨论

• de Raadt, T. “base LoC & committers”, openbsd-misc mailing list, Nov 2020
• Siebenmann, C. “We’re (now) moving from OpenBSD to FreeBSD for firewalls”, University of Toronto CS blog, Nov 2025
• FreeBSD committers-ports.dot, committers-src.dot, committers-doc.dot — FreeBSD Git repository, share/misc/

上一篇：KVM 架构 下一篇：Windows 内核与 Linux 的关键差异