OpenBSD Breaks ABI Defaults to Drive Industry Security, de Raadt Says

Theo de Raadt (ruBSD 2013) — fuckyoustupidzombie

fuckyoustupidzombie

Theo de Raadt argues that operating systems must break backward compatibility to enforce security mitigations by default, leaving OpenBSD to absorb upstream application breakage so the broader software ecosystem can adopt critical defenses without friction.

AI-assisted summary of Theo de Raadt (ruBSD 2013) — original source. Check the original for full context.

Source published:

Key ideas

  • Commercial operating systems like Windows and macOS have aggressively integrated proactive exploit mitigations by methodically updating ABIs, whereas FreeBSD and mainstream Linux distributions have lagged by keeping protections disabled by default. (0:14)
  • OpenBSD acts as an empirical security research vehicle, deploying aggressive mitigations into production—such as early ASLR and malloc guard pages—and tuning them only after real-world performance and third-party software impacts are observed. (8:12)
  • Operating without corporate patrons or formal roadmaps, OpenBSD finances its infrastructure through physical merchandise sales and hackathons while relying on developers scratching their own technical itches. (3:30)
  • By transitioning to 64-bit time_t at the lowest system level across all architectures, OpenBSD patched its entire ports collection to absorb the pain of upstream software breakage for the wider operating system ecosystem. (12:42)

Detailed notes

## Background This video was published on YouTube by user fuckyoustupidzombie on January 30, 2014. The description identifies the speaker as Theo de Raadt, the founder of the OpenBSD project, speaking at the ruBSD 2013 conference.

## TL;DR Theo de Raadt reviews the state of operating system exploit mitigations, contrasting OpenBSD, Microsoft, and Apple's proactive adoption with the reluctance and default-off postures seen across Linux distributions and FreeBSD. He details OpenBSD's operational reality as an entirely volunteer-driven project that relies on physical CD sales rather than corporate grants, while continuing to maintain diverse architectures to expose latent code defects. Finally, de Raadt highlights OpenBSD's philosophy of acting as a living research vehicle—exemplified by pushing radical changes like 64-bit time_t and default ASLR into production to force the broader open-source ecosystem to clean up upstream code.

## Atmosphere & style The presentation carries the candid, pragmatic, and unpretentious vibe of an open-source veteran who has weathered decades of industry cycles and has matured out of overt anger into steady resolve. De Raadt speaks with conversational directness, demystifying the project's gritty daily realities and freely acknowledging technical debts like SMP kernel locking alongside hard-won architectural victories. It feels like an intimate, behind-the-scenes engineering post-mortem where raw software integrity and personal developer motivation consistently take precedence over polished corporate roadmaps.

## Bulletin - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) Commercial operating systems like Windows and macOS have aggressively integrated proactive exploit mitigations by methodically updating ABIs, whereas FreeBSD and mainstream Linux distributions have lagged by keeping protections disabled by default. - [08:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=492s) OpenBSD acts as an empirical security research vehicle, deploying aggressive mitigations into production—such as early ASLR and malloc guard pages—and tuning them only after real-world performance and third-party software impacts are observed. - [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) Operating without corporate patrons or formal roadmaps, OpenBSD finances its infrastructure through physical merchandise sales and hackathons while relying on developers scratching their own technical itches. - [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) By transitioning to 64-bit time_t at the lowest system level across all architectures, OpenBSD patched its entire ports collection to absorb the pain of upstream software breakage for the wider operating system ecosystem.

## Key takeaways - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) Modern compiler warnings have elevated general application code quality, but proactive operating system mitigations are still necessary to trap logic errors and prevent exploitation. - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) Operating system vendors diverge sharply on security mitigations: Microsoft and Apple systematically update their platforms, while Linux distributions leave them fragmented and FreeBSD avoids default stack protection to preserve backward compatibility. - [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) OpenBSD operates on an entirely volunteer basis, allocating foundation donations directly to core operational hosting, bandwidth, and subsidized developer hackathons rather than payroll. - [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) In the tradition of UC Berkeley's CSRG, OpenBSD released critical tools like OpenSSH under unencumbered licenses to benefit the wider computing ecosystem without expecting corporate financial returns. - [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) Maintaining diverse non-x86 architectures such as SPARC64, MIPS, and DEC Alpha serves as a vital diagnostic tool that exposes structural memory, cache, and endianness bugs masked by x86 hardware. - [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) While an Intel monoculture dominates modern networking hardware, OpenBSD continues to confront major technical hurdles around fine-grained SMP kernel locking and native hypervisor virtualization. - [07:17](https://www.youtube.com/watch?v=OXS8ljif9b8&t=437s) Direct appeals for open-ended donations fail to sustain the project, making traditional physical CD sales both a critical financial lifeblood and a community-building mechanism. - [08:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=492s) Aggressive early security implementations required calibration: early ASLR generated excessive page-table memory overhead, and default malloc guard pages triggered crashes in third-party code due to widespread off-by-one errors. - [11:06](https://www.youtube.com/watch?v=OXS8ljif9b8&t=666s) OpenBSD relies on a rigid six-month release cycle with dedicated snapshot windows where widespread user testing exposes flawed assumptions before releases are finalized. - [11:59](https://www.youtube.com/watch?v=OXS8ljif9b8&t=719s) The project operates without top-down roadmaps or speculative feature promises, relying entirely on individual contributor motivation to address specific pain points. - [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) Rather than introducing parallel APIs that third-party developers ignore, OpenBSD addressed the Year 2038 problem by replacing time_t with a 64-bit type directly at the lowest system level across 32-bit and 64-bit platforms alike. - [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) Absorbing the disruption of system-wide changes within the OpenBSD ports tree forces upstream software developers to modernize, allowing other operating systems to adopt these defenses later without breaking application compatibility.

## Detailed walkthrough ### [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) Code Quality, Compiler Warnings, and the OS Mitigation Landscape

Theo de Raadt begins by drawing a firm line between two distinct disciplines in system security: overall code quality and exploit mitigations. When looking strictly at code quality, the state of the art has improved noticeably because modern compilers issue far sharper, more comprehensive warnings. Furthermore, developers have grown more conscientious because a few operating systems now enforce proactive mitigations that catch standard bugs during ordinary execution—not merely security flaws, but everyday logic and memory errors. This has caused software development methodology across the ecosystem to mature.

However, when surveying how different operating system vendors implement exploit mitigations, de Raadt sees a sharp divergence between commercial platforms and certain open-source projects:

* **Microsoft and Apple:** Microsoft has genuinely taken the security mitigation message to heart, methodically stepping their ABI forward so security measures deploy across the whole ecosystem without shattering their broader application base. Apple’s macOS has similarly found a path to activate mitigations and carefully manage backward-compatibility breaks without crippling user software. * **Linux:** De Raadt expresses skepticism about whether the Linux community has fully embraced mitigations, pointing out that while many mitigation techniques technically exist, mainstream distributions typically leave them disabled or only activate them selectively. * **FreeBSD:** FreeBSD lags drastically behind, lacking these mitigations entirely or leaving them turned off by default. Although FreeBSD has mainline support to enable the compiler stack protector (SSP), it remains unactivated, likely because enabling it would require bumping library major versions and breaking backward compatibility. FreeBSD does not even randomize the top of the stack, keeping existing code disabled in the tree, and de Raadt notes that reading their mailing lists reveals no active, systematic source tree auditing.

Regarding legacy application code, de Raadt observes that the worst historic practices have diminished, stating: “No, those problems have mostly gone away. The message has been received by the application writers and largely things are clean.” While unbounded calls like `strcpy` still linger across third-party software, OpenBSD simply flags them with compiler warnings rather than panicking over them as singular threats, since those same risks affect every operating system identically until upstream developers modernize their code.

```mermaid flowchart TD accTitle: OS Security Mitigation Adoption accDescr: Comparison of exploit mitigation adoption across OpenBSD, commercial operating systems, and other open-source projects. subgraph Leaders["Aggressive / Systematic Adoption"] OB["OpenBSD<br/>(Pioneer & default enforcer)"] MS["Microsoft Windows<br/>(Incremental ABI evolution)"] AP["Apple macOS<br/>(Gradual deployment)"] end

subgraph Lagging["Reluctant / Fragmented Adoption"] LX["Linux Distributions<br/>(Features exist, largely disabled by default)"] FB["FreeBSD<br/>(SSP & stack ASLR disabled; backward-compat blockers)"] end

OB -.->|"Influences & proves concepts"| MS OB -.->|"Influences & proves concepts"| AP ```

[03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) Daily OpenBSD Development, Funding, and the Free Software Ethos

Theo de Raadt demystifies the routine operations of the OpenBSD project. There are no paid staff members on payroll; the entire collective operates on volunteer labor. A typical day for de Raadt begins by checking in on what developers have hacked on overnight, processing incoming email, answering architectural questions, and circulating diffs back and forth across the mailing lists. Occasionally, the OpenBSD Foundation channels modest funds toward specific vital milestones—such as paying for development to bring modern X.Org graphics and KMS device drivers into the OpenBSD kernel—but the vast majority of engineering is uncompensated.

When the OpenBSD Foundation collects community donations, it directs the funds straight toward core operational infrastructure:

* Paying for network hosting, bandwidth, and rack infrastructure. * Organizing and subsidizing hackathons, which de Raadt describes as renting cheap group accommodation near university facilities where developers pay their own airfare to gather and write code together.

When asked whether massive corporate enterprises that rely on OpenBSD’s technologies should provide direct financial backing, de Raadt reflects philosophically. While corporate patronage would be welcome, it has never materialized, and he holds no lingering bitterness about it. Recalling the decision to release OpenSSH under an unencumbered license, de Raadt explains:

> “I'm still proud of the fact that we made that decision to make OpenSSH free in that particular way so that nobody would have to write it themselves.”

He views this work as continuing the noble lineage of the Computer Systems Research Group (CSRG) at UC Berkeley: accelerating a concept, validating it inside a real, working operating system, and giving the source code away freely to anyone who wishes to adopt it.

[05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) Aging Out of Anger and Confronting Modern Hardware Challenges

Reflecting on the tone of OpenBSD release songs and project commentary over the years, de Raadt admits that the collective temperament has mellowed over time: “I think we're getting older and we're not as angry anymore, right?” In the project’s earlier eras, release artwork and songs served as direct protests against external disputes—such as chip manufacturers refusing to publish open hardware documentation or the IETF compromising protocol integrity by accommodating software patents. In recent years, rather than mounting vocal public confrontations, the developers have preferred to quietly putter along and focus on shipping code.

The broader hardware ecosystem, however, has transformed dramatically into an Intel monoculture. At the common gigabit networking tier, non-Intel Ethernet controllers have virtually vanished, leaving Intel holding an effective monopoly across network and wireless chipsets. While having fewer hardware vendors simplifies driver breadth, OpenBSD faces substantial technical hurdles:

* **Symmetric Multiprocessing (SMP):** OpenBSD has yet to fully conquer the fine-grained SMP kernel locking challenge and continues working through major performance and scalability issues. * **Modern x86 Virtualization:** The project has not yet built its own native hypervisor solutions for modern x86 virtualization extensions and must take steps to address that domain. * **Multi-Architecture Portability:** Unlike FreeBSD, which focuses its engineering resources on one or two dominant x86-based architectures, OpenBSD maintains active support across older, diverse architectures such as SPARC64, MIPS, and DEC Alpha.

De Raadt stresses that maintaining these non-x86 architectures provides enormous hidden diagnostic value to the codebase. When software breaks due to strict memory alignment, cache quirks, or unusual endianness on an Alpha or SPARC64 box, it exposes fundamental structural bugs that x86 architectures quietly conceal.

[07:17](https://www.youtube.com/watch?v=OXS8ljif9b8&t=437s) Community CD Sales vs. Corporate Foundation Sponsorships

Addressing the project’s perpetual financial constraints, de Raadt explains why OpenBSD has maintained its long-running practice of selling physical CD sets and release merchandise rather than relying on standard corporate grant models. Pure fundraising pleas asking for open donations have yielded poor returns: “The other approaches of just asking for people to fund us so we can keep doing what we're doing, those approaches are not working all that well.” Unlike the deep-pocketed Linux Foundation or the FreeBSD Foundation, OpenBSD possesses no vast roster of commercial corporate underwriters.

Instead, the traditional CD release business serves as both an essential revenue stream and a cultural touchpoint. It provides users a physical way to support development while fostering camaraderie. De Raadt shares fond memories of visiting community members in cities across the world and seeing whole bookshelves lined with colorful jewel cases:

- Loyal users proudly display complete sequential runs of OpenBSD CD sets spanning over a decade of releases. - The only gap in almost every collection is OpenBSD 2.5, simply because the project underestimated demand and did not manufacture enough copies at the time.

[08:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=492s) Bugtraq Roots and the Reality of Address Space & Malloc Mitigations

Reflecting on the evolution of software vulnerability hunting, de Raadt recalls his firsthand involvement in the 1990s Bugtraq disclosure community. He collaborated closely with pioneering security researchers from L0pht and Core SDI during the era when OpenBSD initiated its rigorous, continuous source code audits. Operating systems lacking default mitigations expose their users directly to disaster whenever application bugs emerge, whereas proactive mitigations raise the bar to exploitability to make attacks economically and technically prohibitive. Now that Unix-like systems have become ubiquitous across all consumer electronics and servers, rigorous internal defenses are vital.

De Raadt characterizes OpenBSD as a living research vehicle that discovers practical boundaries by actively deploying aggressive features into production:

> “Somebody has to do the innovation and push things into the ecosystem quickly and try to get a large enough install base so we can actually learn which things work and how they need to be changed.”

He highlights two specific historical experiments that initially overreached and required careful tuning:

1. **Address Space Layout Randomization (ASLR):** Early implementations in OpenBSD were overly aggressive, scattering allocations too chaotically across the virtual address space. This extreme entropy blew up the size of virtual address memory management structures, causing heavy pressure on kernel soft tables, CPU page tables, and hardware translation caches compared to traditional flat memory maps. 2. **Malloc Guard Pages:** The OpenBSD allocator originally inserted guard pages around virtually every memory allocation to trip buffer overruns instantly. However, the OpenBSD Ports developers discovered that widespread real-world third-party software was riddled with small off-by-one errors and memory bugs, causing widespread crashes. The team had to scale back mandatory default guard pages to a less restrictive policy, keeping aggressive guard pages as an opt-in per-application toggle so developers can flush out bugs upstream over time.

De Raadt emphasizes that an engineering team can only learn these critical architectural lessons by shipping changes directly to users and intentionally breaking backward compatibility where necessary—a process enabled by an understanding OpenBSD community that trusts the project's long-term trajectory.

[11:06](https://www.youtube.com/watch?v=OXS8ljif9b8&t=666s) The Six-Month Cycle and Community Testing

Addressing the balance between rapid evolution and stability, Theo de Raadt reflects on how the OpenBSD user and developer communities handle breaking changes. In OpenBSD, users recognize that when backwards compatibility is broken, a particular modification might not immediately benefit their individual setup, but future changes down the line will. This creates an implicit social contract and an essential give-and-take dynamic between developers and the wider user base.

Crucial to this model is OpenBSD’s rigid six-month release cycle. Theo de Raadt emphasizes that there must always be a designated window within that cycle during which a large body of users runs identical snapshot code simultaneously. This widespread real-world deployment serves as the project’s reality check, exposing flawed assumptions or misjudged architectural impacts before a release is finalized. As Theo de Raadt puts it: “there has to be sort of in our six month cycle there has to be a period of time when lots of people run the same code so that if we've made a mistake um if we kind of Mis misjudged the impact of one of our changes that's the time when we're really going to find out and people are going to deploy that code and run with it and it's going to work out fine”. Ultimately, developers rely on learning directly from user deployment to refine those small, cascading side effects.

[11:59](https://www.youtube.com/watch?v=OXS8ljif9b8&t=719s) Developer Motivation and the Absence of Roadmaps

When asked about future plans, Theo de Raadt is candid about the decentralized, itch-scratching ethos that governs OpenBSD. Unlike corporate software projects driven by executive mandates or fixed feature schedules, progress in OpenBSD relies entirely on the personal motivations of its contributors. Developers tackle problems because those problems irritate them personally and demand a solution.

Because of this philosophy, Theo de Raadt refuses to make formal promises about future roadmaps, whether regarding Symmetric Multiprocessing (SMP) scalability or networking performance improvements. He knows his own pain points and has an awareness of what other developers wish to tackle, but he will not promise speculative features to users. As Theo de Raadt explains: “the primary thing that happens in our project is that the developers who make those changes have to want to make those changes they have to have an itch they want to scratch so I don't know what the future road map is”. The only guarantee he is willing to commit to is that there will inevitably be more backwards compatibility breaks in the future—though he reassures the audience that upcoming breaks will be minor in comparison to the massive transition to 64-bit `time_t`.

[12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) The 64-Bit time_t Transition and Dragging the Ecosystem Forward

Theo de Raadt highlights OpenBSD's handling of the Year 2038 problem through its implementation of 64-bit `time_t` across all platforms, including 32-bit architectures. While various theoretical proposals and prototypes for 64-bit time had circulated across the internet for years, no operating system project had fully confronted the logistical nightmare of pushing it completely into production or getting application developers to rewrite their code for separate new time APIs. Rather than introducing alternative parallel APIs, OpenBSD made the radical decision to alter the fundamental type directly at the lowest level of the operating system.

```mermaid flowchart TD accTitle: OpenBSD Upstream Ecosystem Impact accDescr: Diagram illustrating how OpenBSD forces low-level platform changes through its ports tree to fix upstream software for other operating systems.

subgraph OpenBSD_Core["OpenBSD Base System"] A["Low-Level System Change<br>(e.g. 64-bit time_t, ASLR)"] end

subgraph OpenBSD_Ports["OpenBSD Ports Tree"] B["Audit and Patch Third-Party Software<br>(Fix broken assumptions across packages)"] end

subgraph Wider_Ecosystem["Broader Ecosystem"] C["Upstream Open Source Projects<br>(Mozilla, system utilities, daemons)"] D["Other Operating Systems<br>(Can adopt changes by default with zero breakage)"] end

A --> B B --> C C --> D ```

By switching the low-level type, OpenBSD took on the burden of repairing every single package in its ports tree to make it compile and run cleanly with 64-bit time. Theo de Raadt explains that this strategy essentially drags the entire third-party application ecosystem forward: “by the time we get to the point where anybody else wants to actually switch to 64 B time the application space will be ready for them”. He draws a direct parallel between this transition and OpenBSD’s pioneering work on exploit mitigation and Address Space Layout Randomization (ASLR). In both cases, OpenBSD enforced the security and architectural changes system-wide by default, resolving the resulting application failures internally so that downstream and competing operating systems could eventually enable these protections with zero friction. Because OpenBSD forced the ecosystem to adapt, other operating systems can adopt these measures tomorrow knowing that complex consumer software like Mozilla will function without breaking.

- Theoretical 64-bit time solutions avoided low-level ABI breakage by proposing new APIs, but failed because application authors never adopted them. - OpenBSD resolved the problem directly by changing the fundamental time type underneath userland and patching the breakage across the entire ports collection. - This mirrors OpenBSD's earlier deployment of ASLR and exploit mitigations, which proved that modern, complex software stacks can operate under strict security defaults once upstream application assumptions are corrected.

## Notable quotes > [08:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=492s) Somebody has to do the innovation and push things into the ecosystem quickly and try to get a large enough install base so we can actually learn which things work and how they need to be changed. — Theo de Raadt

> [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) I'm still proud of the fact that we made that decision to make OpenSSH free in that particular way so that nobody would have to write it themselves. — Theo de Raadt

## Mentioned Theo de Raadt, OpenBSD, OpenBSD Foundation, OpenSSH, Microsoft, Apple, Linux, FreeBSD, FreeBSD Foundation, Linux Foundation, Computer Systems Research Group (CSRG), UC Berkeley, Intel, Bugtraq, L0pht, Core SDI, Mozilla, X.Org, IETF, SPARC64, MIPS, DEC Alpha

## Video description Theo de Raadt OpenBSD Founder

[Source](https://www.youtube.com/watch?v=OXS8ljif9b8)

中文简报

de Raadt称OpenBSD打破ABI默认设置以推动行业安全 Theo de Raadt认为，操作系统必须打破向后兼容性才能默认强制实施安全缓解措施，从而让OpenBSD承担上游应用程序崩溃的代价，以便更广泛的软件生态系统能够毫无阻力地采用关键防御手段。 Theo de Raadt回顾了操作系统漏洞缓解措施的现状，将OpenBSD、微软和苹果的主动采用与Linux发行版和FreeBSD的犹豫不决及默认关闭态度进行了对比。他详细介绍了OpenBSD作为完全由志愿者推动的项目的运营现实，该项目依靠实体CD销售而非企业资助，同时继续维护多样化的硬件架构以揭示潜在的代码缺陷。最后，de Raadt强调了OpenBSD作为鲜活研究载体的理念——例如将64位time_t和默认ASLR等激进变革推向生产环境，以倒逼更广泛的开源生态系统清理上游代码。 像Windows和macOS这样的商业操作系统通过有计划地更新ABI，积极整合了前瞻性的漏洞缓解措施，而FreeBSD和主流Linux发行版则因默认禁用相关防护而落后。 (0:14) OpenBSD充当着实证安全研究的载体，将激进的缓解措施部署到生产环境中（例如早期的ASLR和malloc保护页），并仅在观察到真实环境性能及第三方软件影响后才进行调整。 (8:12) 在没有企业赞助或正式路线图的情况下，OpenBSD依靠实体周边商品销售和黑客马拉松为其基础设施提供资金，同时依托开发者满足自身的技术诉求开展工作。 (3:30) 通过在所有架构的最底层系统级别过渡到64位time_t，OpenBSD对其整个ports集合进行了修补，从而为更广泛的操作系统生态系统分担了上游软件损坏带来的阵痛。 (12:42)

Reading summary

OpenBSD founder Theo de Raadt argues that advancing operating system security and software reliability requires aggressive, default-on mitigations and low-level architectural breaks. Operating as an independent, volunteer-driven research vehicle, OpenBSD absorbs the friction of fixing broken third-party code to validate technologies that the broader computing ecosystem eventually adopts. Divergent Approaches to System Exploit Mitigations (0:14) Theo de Raadt distinguishes between general code quality and exploit mitigations, noting that while modern compiler warnings have improved baseline programming practices, adoption of proactive defenses diverges sharply across platforms. He credits commercial vendors like Microsoft and Apple with methodically advancing their ABIs to incorporate security mitigations without breaking application ecosystems. In contrast, he argues that Linux distributions often leave mitigation features disabled by default, while FreeBSD lags significantly behind by avoiding compiler stack protection (SSP) and stack randomization to preserve backward compatibility, alongside an absence of systematic source code auditing. OpenBSD relies on continuous production deployment to test and refine mitigations, drawing on de Raadt's roots in the Bugtraq and L0pht vulnerability communities to make exploits economically prohibitive. This experimental deployment has sometimes required recalibration. An early Address Space Layout Randomization (ASLR) implementation scattered allocations so chaotically that it inflated virtual memory management structures and degraded CPU cache performance. Similarly, aggressive default malloc guard pages exposed widespread off-by-one errors across third-party software, forcing the project to scale guard pages back to an opt-in toggle to balance security with functional stability. Absorbing Ecosystem Friction Through Breaking Changes (12:42) OpenBSD avoids speculative feature roadmaps, operating instead on a decentralized model where volunteer contributors address issues that personally affect them. The project pairs this ethos with a rigid six-month release cycle featuring a synchronized snapshot testing window. During this phase, broad community deployment acts as a reality check for misjudged architectural changes. Users tolerate backward-compatibility breaks under an implicit social contract, recognizing that near-term disruptions yield long-term platform resilience. This philosophy is illustrated by OpenBSD's response to the Year 2038 problem. Rather than implementing parallel, opt-in time APIs that application developers historically ignore, OpenBSD switched the underlying time_t type directly to 64 bits across all architectures, including 32-bit platforms. The project absorbed the burden of auditing and patching its entire ports collection so complex software like Mozilla would function cleanly. De Raadt asserts that this mirrors OpenBSD's earlier ASLR and mitigation work: by enforcing strict defaults internally, OpenBSD cleans up upstream code assumptions so competing operating systems can later adopt the changes without application breakage. Hardware Monoculture and Diagnostic Architecture Support (5:12) The broader computing landscape has increasingly narrowed into an Intel monoculture, particularly within gigabit Ethernet and wireless chipsets. While reduced vendor variety limits the breadth of hardware drivers OpenBSD must author, the platform continues to face demanding technical challenges, such as implementing fine-grained kernel locking for symmetric multiprocessing (SMP) and developing native hypervisors for modern x86 virtualization. Despite the dominance of x86, OpenBSD maintains active support for non-x86 architectures, including SPARC64, MIPS, and DEC Alpha. De Raadt emphasizes that maintaining these legacy and diverse platforms serves a vital diagnostic function. Running the codebase on architectures with strict memory alignment requirements, unique cache dynamics, and non-standard endianness immediately exposes structural bugs that lenient x86 processors quietly mask. Volunteer Operations and Project Independence (3:30) OpenBSD operates entirely without salaried employees, coordinating volunteer labor through mailing lists and staging foundation-subsidized hackathons. Although major corporate enterprises widely integrate OpenBSD components like OpenSSH, direct corporate funding has never materialized. De Raadt expresses no resentment over this dynamic, framing the unencumbered licensing of OpenSSH as an extension of UC Berkeley’s Computer Systems Research Group (CSRG) tradition of proving ideas in a working system and giving the code away freely. To preserve operational independence, the project relies on physical CD set and merchandise sales alongside modest donations, avoiding standard corporate underwriting models. Over time, the project's public temperament has also mellowed; earlier release songs and artwork that directly protested software patents or uncooperative hardware vendors have given way to a quieter focus on shipping functional code. Theo de Raadt positions OpenBSD as an unapologetic testing ground that advances software security by enforcing strict defaults and absorbing the labor of broken compatibility. Even as the project navigates ongoing technical hurdles in kernel locking and virtualization, its willingness to break low-level interfaces continues to drive proactive security and modernization across the wider computing landscape.

精炼阅读摘要

OpenBSD 创始人 Theo de Raadt 指出，OpenBSD 的核心定位是充当系统安全的先行探索平台，通过率先默认强制推行激进的漏洞防御并主动打破向后兼容性，承担修复第三方应用缺陷的成本，进而推动整个操作系统生态系统向前演化。 系统级防御与操作系统阵营的分化 (0:14) De Raadt 将代码质量与漏洞利用防御划分为两个不同领域。他认为，得益于现代编译器更为敏锐的警告机制以及部分系统在运行时主动暴露逻辑缺陷，行业整体代码质量已有显著提升。但在操作系统漏洞防御机制的实装上，各平台出现了明显分化：商业阵营中的 Microsoft Windows 与 Apple macOS 采取系统化演进路径，通过审慎调整 ABI 在不破坏应用基础的前提下稳步普及防御技术；开源阵营的 Linux 虽然具备相关机制，但在主流发行版中大多默认禁用或仅作零星配置。 试错调整与默认防御的实际代价 (8:12) De Raadt 指出 FreeBSD 在安全机制演化上严重滞后，因顾虑主版本号递增带来的兼容性断裂，长期未在主线默认启用堆栈保护器（SSP），未实现栈顶地址随机化，且邮件列表中未见系统性的源码安全审计。De Raadt 结合自身在 1990 年代 Bugtraq 审计经验强调，缺乏默认防御的系统会在应用出现漏洞时将用户置于巨大风险之中。然而，防御机制的探索并非一蹴而就：OpenBSD 早期的 ASLR 曾因过度离散虚拟地址分配而导致内核与页表内存管理结构急剧膨胀；分配器默认在每次申请时插入保护页（Guard Pages）的激进做法，也因触发了上游第三方软件中普遍存在的微小越界问题而不得不退让，最终将严格保护页调整为应用程序的按需开启选项。 志愿开发机制与非商业化运作理念 (3:30) OpenBSD 项目全员依托志愿者协同推进，不设立受薪岗位。日常开发由贡献者根据自身痛点提交补丁，并通过邮件列表进行代码审查。虽然 Linux 基金会与 FreeBSD 基金会有雄厚商业赞助，但 OpenBSD 并未获得依赖该技术的科技巨头资助；对此 De Raadt 态度平和，将其比作 UC Berkeley CSRG 自由软件传统的延续——验证概念并在可用操作系统中免费开放成果（如 OpenSSH）。项目长期主要依靠向社区销售实体安装光盘与纪念周边来覆盖带宽托管和黑客松场地开销。由于完全由开发者的个人解决意愿驱动，De Raadt 明确拒绝对外承诺任何未经证实的功能路线图。 硬件单极化与非主流架构的诊断价值 (5:12) 随着项目成员年龄增长，OpenBSD 逐渐减少了以往针对硬件封闭或专利争议的公开激烈抗争，转向低调交付代码。然而当前硬件市场已形成 Intel 对千兆以太网和无线芯片的高度垄断。在平台能力方面，OpenBSD 仍面临多核细粒度内核锁（SMP）的性能扩展瓶颈，且尚未构建原生的现代 x86 虚拟化 Hypervisor。不过，与将资源高度收敛于 x86 架构的 FreeBSD 不同，OpenBSD 坚持维护 SPARC64、MIPS 和 DEC Alpha 等老旧架构。De Raadt 强调，这些平台对内存严格对齐、特殊缓存行为和字节序的严苛要求，能够成为极佳的诊断工具，有效暴露被 x86 宽松容错机制所隐匿的底层代码缺陷。 六个月发布周期与强制推进生态演进 (11:06) 为了在剧烈变革与生产稳定性之间取得平衡，OpenBSD 恪守严格的六个月发布周期，并确保在周期内留出特定窗口供大量用户运行一致的快照代码，以检验设计假设并暴露连锁影响。最具代表性的实践是 OpenBSD 对 2038 年问题的处置：与其像业内以往那样停留在讨论阶段或引入平行的全新 API，OpenBSD 直接在最底层将所有平台（含 32 位架构）的 `time_t` 改为 64 位，并承担了修补整个 Ports 软件仓库兼容性断裂的繁重工程。De Raadt 指出，这种硬性变更迫使上游软件（如 Mozilla）修正时间假设，正如当年 OpenBSD 强推 ASLR 迫使应用层清理违规操作一样，最终让下游和其他操作系统得以在未来零成本、无阻碍地默认启用这些关键特性。 Theo de Raadt 总结认为，OpenBSD 的核心价值在于充当整个操作系统的先锋试验场，通过在生产环境中直接承受破坏兼容性的适配阵痛，带动上游软件清理隐患并向行业验证防御机制的可行性。在缺乏商业赞助与纯志愿开发的限制下，项目未来的核心工程挑战仍在于如何在维持多架构代码质量的同时，攻克内核细粒度多核扩展性与虚拟化支持。

Detailed notes — zh

## Background 本内容由 YouTube 用户 fuckyoustupidzombie 于 2014 年 1 月 30 日发布。视频记录了 OpenBSD 创始人 Theo de Raadt 在 ruBSD 2013 大会上的受访与分享，页面简介明确标示了其作为 OpenBSD 创始人的身份。 ## TL;DR Theo de Raadt 深入对比了各大操作系统对现代漏洞缓解机制的采纳现状，赞扬了微软和苹果的前瞻性，同时批评了 Linux 发行版与 FreeBSD 在默认安全防护上的保守与滞后。他详细介绍了 OpenBSD 纯志愿者、零全职雇员的极简运转机制，并解释了为何坚持支持 SPARC64、Alpha 等陈旧异构架构以排查深层缺陷。最后，他阐述了 OpenBSD 宁可牺牲向后兼容性也要充当激进技术试验场的独特使命，展示了项目如何率先全面切换 64 位 time_t 与推行 ASLR，替整个开源应用生态扫清底层隐患。 ## Atmosphere & style 访谈流露着一种老派黑客独有的务实、坦率与从容沉稳。Theo de Raadt 褪去了年轻时激进对抗的棱角，以略带自嘲却无比坚定的口吻，直白点评业界巨头与竞争系统的技术短板。聆听过程中既能感受到团队在微薄资金下长年坚守哲学的纯粹情怀，也能体会到作为操作系统拓荒先锋、为全人类软件生态“排雷”的深沉自豪感。 ## Bulletin - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) Theo de Raadt 批评主流 Linux 发行版与 FreeBSD 忽视安全缓解机制，抨击 Linux 虽拥有相关技术却大部分默认禁用，而 FreeBSD 连最基础的栈顶随机化和栈保护都处于停用状态。 - [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) OpenBSD 整个核心团队无任何受薪雇员，完全由全球志愿者驱动，有限的捐赠资金仅用于覆盖网络带宽账单与补贴每年线下 Hackathon 的廉价住宿。 - [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) 坚持在 SPARC64、MIPS 和 DEC Alpha 等陈旧异构架构上维护内核，利用极端内存对齐和弱内存模型等硬件特性逼出底层深层缺陷，构成了 OpenBSD 独特的工程质量检验机制。 - [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) OpenBSD 充当激进的安全试验场，通过在底层强推 64 位 time_t 与 ASLR 并全面修复 Ports 软件树，为整个开源软件生态（如 Mozilla）趟平兼容性暗坑，使后续采纳者无需再承担生态碎裂风险。 ## Key takeaways - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) 安全防御需严格区隔代码质量改进与运行时缓解机制（Mitigations）两个维度，现代编译器的静态分析虽普遍提升了代码质量，但主动缓解机制的部署在各操作系统间差异巨大。 - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) 在主流商业操作系统中，微软对现代安全缓解技术的落地理解最为深刻，macOS 紧随其后，两者皆找到了在渐进演进 ABI 的同时平滑保护应用生态的可行路径。 - [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) FreeBSD 因过分恪守向后兼容性而不敢轻易升级函数库版本，源码树中即便存在栈保护补丁也默认关闭，邮件列表亦缺乏主动的安全审计动作。 - [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) OpenBSD 秉承纯粹的志愿者黑客协作模式，不设全职受薪职位，开发者通过邮件列表互发 diff 推进日常开发。 - [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) OpenSSH 坚持彻底无限制免费开源，消除了全球软件产业重复造轮子的成本，践行了贝尔实验室与加利福尼亚大学伯克利分校 CSRG 的学术开源馈赠精神。 - [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) 团队黑客文化随着成员成熟而趋于内敛，早期对抗硬件厂商不开源与 IETF 专利绑定的激烈愤怒情绪已转为安稳专注的系统底层打磨。 - [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) 千兆以太网和无线网卡领域近乎被英特尔垄断，硬件生态的多样性丧失导致驱动适配工作高度受制于单一厂商。 - [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) 拒绝走仅聚焦主流主流平台的路线，坚守 SPARC64、MIPS、Alpha 等小众架构是利用异构 CPU 特性捕捉深层代码隐患的不可替代手段。 - [07:17](https://www.youtube.com/watch?v=OXS8ljif9b8&t=437s) OpenBSD 将自身定位为激进的操作系统研发实验室，甘愿以打破向后兼容性为代价，在真实大规模用户环境中验证防御原型的有效性。 - [07:17](https://www.youtube.com/watch?v=OXS8ljif9b8&t=437s) 安全机制演化伴随碰壁与妥协：早期 ASLR 因过度打散导致虚存管理结构和页表超载，malloc 堆保护也因现实中第三方软件普遍存在内存越界而被迫从强制插入退回按需开启。 - [11:06](https://www.youtube.com/watch?v=OXS8ljif9b8&t=666s) 用户社区与开发者之间存在互谅互让的契约，用户承受向后兼容性打破的阵痛，换取系统长期的整洁度与更高级别的安全防护。 - [11:06](https://www.youtube.com/watch?v=OXS8ljif9b8&t=666s) 项目拒绝设定空洞宏大的路线图，代码演进完全由志愿开发者的内生诉求与具体解决自身痛点（scratching an itch）的意愿决定。 - [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) 彻底解决 2038 年问题的关键在于跳过虚浮的过渡性 API，在最底层直接把 time_t 切换为 64 位整数，并通过重构自身 Ports 树倒逼上游开源生态跟进修复。 - [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) OpenBSD 承担了推行严苛安全机制的“除雷兵”角色，确保大型复杂软件在防御环境下稳定运行，为其他操作系统后续默认开启同类机制扫清了障碍。 ## Detailed walkthrough ### [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) 操作系统安全缓解措施与生态各方的采纳现状 Theo de Raadt 强调在讨论系统安全性时，必须清晰地区分两个层面：其一是代码本身的质量（code quality），其二则是漏洞缓解机制（mitigations）。就代码质量而言，现代编译器的进化带来了更好的警告提示，开发者们也变得更加谨慎；由于部分操作系统引入了缓解机制，这些机制会触发常规程序错误而不仅仅是安全漏洞，促使整个业界的编码方法论得到了实质性改善。然而，在主流操作系统的安全缓解机制部署上，各大厂商的态度存在巨大鸿沟。Theo 直言指出：“I think Microsoft has really gotten the message I'm not quite sure if the Linux crowd has gotten the message because all these mitigations that are available now these techniques they have they' largely have them turned off”，抨击主流 Linux 发行版尽管手握这些技术，却绝大部分处于默认关闭状态，仅偶尔启用，未能真正进入主线生产环境。 对于 FreeBSD，Theo 的评价尤为尖锐。他指出 FreeBSD 几乎没有任何这类缓解机制，即便源码树里包含了诸如开启栈保护（Stack Protector）或随机化栈顶（randomize the top of stack）的代码补丁，也全部默认处于禁用状态。FreeBSD 似乎始终不敢打破向后兼容性（backwards compatibility）去升级函数库版本，更看不到其邮件列表里有任何对源码树展开积极安全审计的迹象。相比之下，Theo 将微软列为采用安全缓解技术的表率，而苹果的 macOS 紧随其后名列第二。macOS 和微软都找到了在推进 ABI 与安全机制的同时平滑保护现有应用生态的方法。至于传统的无界字符串拷贝函数（如 `strcpy`），Theo 坦承虽然上层软件中仍随处可见，OpenBSD 也会报出编译警告，但由于这是所有操作系统共同面临的普遍风险，只能交由时间去逐步改进。 ```mermaid flowchart TD accTitle: 各大系统对安全缓解技术的部署策略对比 accDescr: 对比OpenBSD、微软与macOS、Linux主线及FreeBSD在安全机制启用和兼容性取舍上的不同态度 subgraph Leading["积极推进阵营"] OBSD["OpenBSD<br/>激进默认开启 / 敢于牺牲向后兼容"] MS_APPLE["Microsoft & Apple (macOS)<br/>逐步升级 ABI / 兼顾生态与缓解机制落地"] end subgraph Lagging["滞后观望阵营"] LINUX["Linux 主流发行版<br/>技术完备但绝大部分默认关闭"] FBSD["FreeBSD<br/>无实质缓解 / 栈保护代码默认禁用 / 困于向后兼容"] end OBSD -.->|"生态创新示范"| MS_APPLE MS_APPLE -.->|"拉开安全差距"| LINUX LINUX -.->|"缺乏主线普及"| FBSD ``` - 现代编译器提供了更严格的静态警告，从底层促使通用软件代码质量提高。 - 微软深刻理解了现代缓解措施的价值，在 Windows 生态中广泛落地。 - macOS 位列第二，通过渐进演进 ABI 的方式引入缓解技术，未破坏上层应用兼容性。 - 主流 Linux 社区未能在发行版核心默认启用大多数现成防御技术。 - FreeBSD 连最基础的栈顶随机化都未部署，代码长期处于停用状态。 ### [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) OpenBSD 的纯志愿者运作模式与开发日常 谈及个人日常工作，Theo de Raadt 描绘了一幅纯粹的开源黑客生活图景：每天清晨醒来，第一件事就是查看全球各地的开发者提交了哪些新成果，随后处理海量电子邮件，在讨论中解答疑问、提出反馈，并与同伴互发代码补丁（diffs）。在整个 OpenBSD 核心团队中，没有哪怕一个人是拿薪水的全职雇员，所有人都是纯粹的志愿者。此前，OpenBSD 基金会（OpenBSD Foundation）曾拨出一小笔专款，以确保全新的图形驱动架构（X device driver 代码）能顺利集成进内核，除此类极特殊情况外，系统的每一个部件全部仰赖志愿者无偿贡献。 对于外界关于“OpenBSD 拥有海量企业用户却为何未获巨额赞助”的疑问，Theo 表现得十分释怀。基金会收到的零星捐款几乎全部直接用于支付服务器网络带宽费用，剩余部分则用来资助每年举办的 Hackathon（黑客松）——其开销极为朴素，通常只是大学周边廉价的住宿床位，连往返机票都多由开发者自掏腰包。面对大型科技公司免费使用代码却不回馈的现实，Theo 坚定地为当年彻底免费开源 OpenSSH 的决定感到自豪：“I'm still proud of the fact that we made that decision to make open SSH free in that particular way so that nobody would have to write it themselves”。他认为 OpenBSD 的使命就是像当年的伯克利计算机系统研究组（CSRG）一样，验证技术可行性并照亮前路，供全人类自由采用。 - OpenBSD 无全职受薪雇员，完全依靠分布式社区志愿者通过 diff 协作推进。 - OpenBSD 基金会的有限善款首要保障基础设施网络账单，其次补贴线下黑客松的平价住宿。 - 开发者参加线下黑客松通常自理差旅交通开销。 - OpenSSH 彻底免除了全球软件界重复造轮子的负担，践行了贝尔实验室与 CSRG 的学术开源精神。 ### [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) 黑客的成熟、硬件单一化与多架构支持的哲学执念 随着项目历经数十载岁月，OpenBSD 的文化风貌也在悄然演变。昔日每个版本发布时附带的讽刺歌曲，往往源于激烈的阵营对抗——例如要求硬件厂商公开芯片规格文档，或抗议 IETF 允许专利技术捆绑网络协议；而今，Theo 笑言大家年纪渐长，不再像年轻时那样充满愤怒（“I think we're getting older and we're not as Angry Anymore”），过去几年项目只是安稳专注地默默打磨系统。与此呼应的是硬件生态的急剧单调化：百家争鸣的硬件厂商几乎消失，英特尔在常规千兆以太网和无线网卡领域近乎垄断，使得适配工作在“应对 Intel 驱动垄断”上耗费的精力远超其他小众设备。 即便在 x86 占据绝对统治地位的今天，OpenBSD 依然面临着多核对称多处理（SMP）重构和现代 x86 硬件虚拟化（VM）支持不足的严峻挑战。但在架构路线上，OpenBSD 坚决不走 FreeBSD 那样仅聚焦一两款主流主流架构的路线。Theo 强调，OpenBSD 坚持在 SPARC64、MIPS 和 DEC Alpha 等全套陈旧架构（legacy architectures）上运行内核，具有不可替代的工程价值：“we find a bug on spark 64 because it has certain characteristics or we find it on a myip processor or we find it on the Alpha and we still find tremendous benefits from that”。异构平台的极端特性（如内存对齐、弱内存模型、大小端序）能够天然逼出深藏的系统级隐患，成为最严苛的代码试验场。 - 团队从早期的抗议型黑客文化转向专注于系统内部演进的内敛状态。 - PC 与服务器网络芯片高度被英特尔垄断，常规千兆网络市场缺乏竞争。 - SMP 性能优化与基于硬件辅助的 x86 虚拟机技术是当前项目的技术追赶重点。 - 坚守 SPARC64、MIPS、Alpha 等小众陈旧硬件架构，利用不同 CPU 架构特性来捕获深层边界缺陷。 ### [07:17](https://www.youtube.com/watch?v=OXS8ljif9b8&t=437s) 经费困局、光盘情怀与作为激进安全试验场的使命 谈及长期维系生存的资金困境，Theo 坦言靠单纯呼吁捐款维生举步维艰。OpenBSD 没有任何巨头资助，资源实力根本无法与拥有雄厚财力背景的 Linux 基金会或 FreeBSD 基金会同日而语。多年来，项目组依赖销售实体安装光盘维系运营；尽管这并非一门高利润的生意，但它构筑了不可替代的情感纽带。Theo 动情地回忆起自己在世界各地的城市走访用户时，看到狂热拥趸书架上整整齐齐码放着历代 OpenBSD 实体盒装光盘时的自豪，甚至有人会为唯独漏掉了当年限量发售的 2.5 版本而扼腕叹息。 面对 1990 年代 Bugtraq 时代全面信息披露（Full Disclosure）运动以来的网络安全恶化，Theo 坚信安全缓解技术的意义在于大幅拉高黑客的攻击门槛。他认为 OpenBSD 的定位本质上是一个“激进的操作系统研发实验室”（research space），必须充当敢于率先踩坑的先锋。为了摸清安全防御技术的边界，OpenBSD 敢于以打破向后兼容为代价，将最前沿的防御原型推向用户真实环境检验： “somebody has to do the Innovation and push things into the ecosystem quickly and tried to get a large enough install base so we can actually learn which things work and how they need to be changed” Theo 详细举例复盘了这种探索过程中的挫折与妥协： 1. **地址空间布局随机化（ASLR）**：早期 OpenBSD 的实现过于激进贪婪，过度打散虚存导致页表（Page Tables）和 CPU 缓存承受了过载压力，内核管理虚存的软表膨胀到异常庞大，最终团队不得不回调了随机化粒度。 2. **Malloc 堆保护机制（Guard Pages）**：最初内核在动态内存分配中肆无忌惮地到处插入保护页，结果引发了灾难性后果——外部现实世界中的第三方软件代码质量极其糟糕，隐藏着海量内存越界暗病，导致各类 Ports 移植软件频繁崩溃，开发者苦不堪言。团队不得不撤回全盘强制插入保护页的激进策略，改为按程序按需开启。 通过依靠宽容且高度理解项目愿景的核心社区，OpenBSD 承受住了打破兼容性的阵痛，在无数次碰壁与回退中探索出了真实软件生态与系统强防御共存的最佳平衡点。 - 资金规模远逊于 Linux 基金会和 FreeBSD 基金会，早年极大程度仰赖官方光盘发行维系开支。 - 历史版本 2.5 光盘因当年生产数量有限，成为狂热收藏玩家心中的稀有珍品。 - ASLR 早期因随机化过度，导致内核虚拟内存管理结构和硬件页表负担超载，后经调优收敛。 - `malloc` 堆防护因真实第三方软件普遍存在的内存越界缺陷而被迫妥协，由全盘防护改为渐进式按需开启。 - 牺牲陈旧二进制兼容性换取安全机制的大规模实战演练，是 OpenBSD 推动业界技术演进的核心模式。 ### [11:06](https://www.youtube.com/watch?v=OXS8ljif9b8&t=666s) 社区互惠机制与以开发者驱动的演进模式 Theo de Raadt 探讨了 OpenBSD 社区内部对于“破坏向后兼容性”的包容度与平衡机制。他指出，用户们其实明白，并非每一次打破向后兼容性的改动都直接契合自身需求或为自己量身定制，但其他某些改动必定会让他们受益，这构成了用户社区与开发社区之间一种“互谅互让、各取所需（give-and-take）”的良性生态。在 OpenBSD 每六个月一次的发布周期中，必须存在一段特定时期让大量用户集中运行相同的代码；唯有如此，一旦开发团队犯下错误或误判了某项变更带来的波及效应，才能在真实的大规模部署与运行中被及时发现并化解。Theo 强调，团队必须持续倾听并从用户的实际反馈中汲取教训。 谈及未来的发展规划，Theo 明确表示 OpenBSD 并不遵循预设的宏大路线图，因为项目推进的核心动力完全源于开发者内生的诉求与兴趣。开发者必须自己渴望做出一项修改，或者“有想要去挠的痒处”，代码变更才会发生。因此，除了明确知道困扰自己并亟待改进的痛点，以及其他个别开发者想要优化的环节之外，他拒绝就未来的 SMP（对称多处理）优化或网络性能提升做出任何空头承诺。不过，他幽默而确定地保证未来必定还会出现打破向后兼容性的情况，只是其影响规模都无法与近期实施的 64 位 `time_t` 改动相提并论。 Theo de Raadt 阐述项目演进理念时直言：“The primary thing that happens in our project is that the developers who make those changes have to want to make those changes they have to have an itch they want to scratch so I don't know what the future road map is.”（在我们项目中，最核心的事情是做出这些改动的开发者必须自己想去改，他们必须有自己想挠的痒处；所以我不知道未来的路线图是什么。） - **互惠的社区契约**：用户接受短期内可能不直接惠及自身的 API 或 ABI 变动，换取系统长期获得更彻底的底层清理与功能改进。 - **六个月发布周期中的验证窗口**：依靠广泛的用户群在统一代码基上运行测试，以暴露隐蔽的设计缺陷与回归问题。 - **无固定路线图原则**：拒绝在 SMP 或网络吞吐量等方向上给出空洞的里程碑承诺，开发重点完全由志愿开发者的实际兴趣和解决具体痛点的意愿驱动。 --- ### [12:42](https://www.youtube.com/watch?v=OXS8ljif9b8&t=762s) 激进推进 64 位时间戳与引领应用生态变革 Theo 详细回顾了 OpenBSD 针对 2038 年问题的核心举措——全面切换至 64 位 `time_t`。他提到，理论上处理 64 位时间戳的方式多种多样，网络上随处可见各方提出的原型设计，但此前从未有人真正将这种改动一路贯彻推进行至完整的操作系统底层，更没有人去通盘考虑如何引导所有应用层程序员适配一套全新 API 的繁重后勤工作。OpenBSD 摒弃了复杂的折中妥协，选择在极其底层的类型定义上直接完成切换。这一激进举措迅速推动了整个生态的跟进：如今 OpenBSD 的整个 Ports 软件仓库均已在 64 位时间戳下编译并顺畅运行，实际上是由 OpenBSD 强行拖拽着庞大的上游应用程序基础向前迈进。 Theo 解释称，这种做法与 OpenBSD 过去推行漏洞防御技术（Exploit Mitigation）和地址空间布局随机化（ASLR）时的路径如出一辙。通过在真实的生产级操作系统中率先默认启用这些严苛的安全机制，OpenBSD 承担了暴露错误并修复应用软件生态的前哨成本。这样一来，当其他操作系统未来某天决定默认启用类似机制或切换到 64 位时间戳时，整个应用软件生态早已成熟稳定，不必再为底层兼容性提心吊胆。 Theo de Raadt 在总结这一开创性工作时自豪地指出：“Anybody tomorrow in their operating system can turn these things on by default they don't have to worry Mozilla is going to work we've made sure of that.”（明天任何人在他们自己的操作系统里把这些功能默认开启，都不用担心浏览器跑不起来；Mozilla 能正常工作，因为我们已经确保了这一点。） ```mermaid flowchart TD accTitle: OpenBSD 引领生态迁移的工作流 accDescr: 展示 OpenBSD 如何在底层直接实施激进改动，修复自身 Ports 树，进而将兼容性成果反哺整个开源应用生态。 subgraph OpenBSD["OpenBSD 核心推进"] A["底层激进改造<br/>(直接更改 64 位 time_t / 强推 ASLR)"] --> B["全面重构与适配<br/>OpenBSD Ports 软件树"] end subgraph Upstream["上游与下游生态受益"] B --> C["修复复杂应用兼容性<br/>(如适配 Mozilla 等大型项目)"] C --> D["推动上游应用软件基础成熟"] D --> E["其他操作系统未来直接默认启用<br/>无需承担应用生态碎裂风险"] end ``` - **底层直改而非层层包裹**：跳过虚浮的过渡 API 理论构想，直接在系统最底层修改时间戳类型定义。 - **以 Ports 树带动全球应用兼容**：借助对数万个第三方软件的移植与修复，倒逼开源社区彻底解决 2038 年时间截断与溢出问题。 - **铺平行业安全防线**：类似于此前率先强推 ASLR 与漏洞利用缓解技术，OpenBSD 充当开源应用生态的“除雷兵”，确保主流重型软件（如 Mozilla 套件）在严苛机制下依然稳定运行。 ## Notable quotes > [07:17](https://www.youtube.com/watch?v=OXS8ljif9b8&t=437s) somebody has to do the Innovation and push things into the ecosystem quickly and tried to get a large enough install base so we can actually learn which things work and how they need to be changed — Theo de Raadt > [00:14](https://www.youtube.com/watch?v=OXS8ljif9b8&t=14s) I think Microsoft has really gotten the message I'm not quite sure if the Linux crowd has gotten the message because all these mitigations that are available now these techniques they have they' largely have them turned off — Theo de Raadt > [03:30](https://www.youtube.com/watch?v=OXS8ljif9b8&t=210s) I'm still proud of the fact that we made that decision to make open SSH free in that particular way so that nobody would have to write it themselves — Theo de Raadt > [11:06](https://www.youtube.com/watch?v=OXS8ljif9b8&t=666s) The primary thing that happens in our project is that the developers who make those changes have to want to make those changes they have to have an itch they want to scratch so I don't know what the future road map is. — Theo de Raadt > [05:12](https://www.youtube.com/watch?v=OXS8ljif9b8&t=312s) I think we're getting older and we're not as Angry Anymore — Theo de Raadt ## Mentioned Theo de Raadt, OpenBSD, OpenBSD Foundation, FreeBSD, FreeBSD Foundation, Linux, Linux Foundation, Microsoft, Apple, macOS, OpenSSH, Intel, SPARC64, MIPS, DEC Alpha, IETF, Mozilla, CSRG, Bugtraq ## Video description Theo de Raadt OpenBSD Founder [Source](https://www.youtube.com/watch?v=OXS8ljif9b8)

Source quotes

[7:17] Theo de Raadt: somebody has to do the Innovation and push things into the ecosystem quickly and tried to get a large enough install base so we can actually learn which things work and how they need to be changed [0:14] Theo de Raadt: I think Microsoft has really gotten the message I'm not quite sure if the Linux crowd has gotten the message because all these mitigations that are available now these techniques they have they' largely have them turned off [3:30] Theo de Raadt: I'm still proud of the fact that we made that decision to make open SSH free in that particular way so that nobody would have to write it themselves [11:06] Theo de Raadt: The primary thing that happens in our project is that the developers who make those changes have to want to make those changes they have to have an itch they want to scratch so I don't know what the future road map is. [5:12] Theo de Raadt: I think we're getting older and we're not as Angry Anymore

Source quotes

[8:12] Theo de Raadt: Somebody has to do the innovation and push things into the ecosystem quickly and try to get a large enough install base so we can actually learn which things work and how they need to be changed. [3:30] Theo de Raadt: I'm still proud of the fact that we made that decision to make OpenSSH free in that particular way so that nobody would have to write it themselves.

Original transcript

[0:14] I think we should separate this into two [0:16] pieces one is the code quality aspect [0:18] and the other one is the [0:20] mitigations um speaking just about code [0:23] quality the compilers have gotten better [0:25] they give better warnings and so code [0:27] quality in general has gotten better uh [0:29] people are more careful because there [0:31] are a few systems which have mitigations [0:33] and those mitigations trigger standard [0:35] bugs not just security bugs but bugs and [0:39] therefore [0:40] the the the methodology that people [0:42] throw into actually writing code has [0:43] improved a little bit um as far as the [0:47] the the greater um vendor um space of [0:51] actually writing operating systems [0:54] um I think Microsoft has really gotten [0:57] the message I'm not quite sure if the [0:59] Linux crowd has gotten the message [1:01] because all these mitigations that are [1:03] available now these techniques they have [1:05] uh they' largely have them turned off [1:07] they they only turn them on occasionally [1:10] uh they're they're not deployed in the [1:12] uh in the main um in in the main stream [1:23] distributions frsd has none of these [1:26] mitigations at all um maybe they have a [1:29] patch here ti2 um for example they they [1:33] they have some support in their main [1:35] line to turn on the stack protector now [1:37] but they don't turn it on and uh they [1:40] probably will have to crank their [1:41] libraries and um make [1:44] um make make a break with backwards [1:46] compatibility before they're able to [1:47] actually make that jump they don't even [1:49] randomize the top of the stack yet they [1:51] have code in their tree it's still [1:52] disabled these are very very minor [1:54] medications and they haven't even [1:56] deployed those and I I don't see the the [1:58] um the I don't see [2:00] from Reading their man lists I don't see [2:02] any active auditing of their Source [2:08] tree they're number two for mitigations [2:11] they've turned almost all of them on um [2:14] Mac OS uh is very interesting they're [2:16] starting to turn the mitigations on and [2:18] it sounds it feels to me like they kind [2:20] of have found a path that allows them [2:23] to um break backward compatibility but [2:27] not in a way so that it harms their um [2:30] their application base so that that I [2:32] think is the same thing that Microsoft [2:34] has done is they've decided that hey we [2:37] can actually start deploying these into [2:38] the ecosystem and it won't hurt our [2:40] applications because they've been [2:41] careful and they have they have a [2:43] process for moving the ABI forward step [2:46] by step as they introduce these [2:54] things no those problems have mostly [2:57] gone away the message has been received [2:59] by the application writers and um [3:01] largely things are clean you you still [3:03] see uh string copies unbounded calls in [3:07] a lot of these pieces of software but um [3:10] we we generate warnings for those um but [3:12] we don't worry about them being being uh [3:15] uh a risk per se because they're a risk [3:17] on every operating system as well right [3:20] so uh we hope that as time goes by those [3:22] get improved but that's the best we can [3:24] do [3:30] my day today is I wake up and I see what [3:33] the developers have have been working on [3:37] and uh I help them uh I process my email [3:40] answer questions uh I ask questions we [3:43] just exchange diffs there's a nobody in [3:46] the group who's an active paid employee [3:48] uh everybody's just a volunteer we have [3:51] thrown um the open be Foundation through [3:54] a little bit of money um to ensure that [3:57] um the the new X stuff the device driver [4:00] stuff would actually happen inside our [4:01] kernel but largely every other piece is [4:04] being done uh completely on a volunteer [4:06] basis um and then you ask about the open [4:09] D foundation so they take donations um [4:13] and they final them basically directly [4:14] into the payment of our of our [4:16] Network and the rest of it they use to [4:19] fund our hackathons which is pretty much [4:21] just a cheap accommodation near [4:23] University facility somewhere developers [4:26] fly themselves in [4:32] uh you know you should have a support [4:34] from big companies who uses that codes [4:37] uh it'd be nice but it hasn't happened [4:41] I'm still proud of the fact that we made [4:43] that decision to make open SSH free in [4:46] that particular way so that nobody would [4:48] have to write it themselves uh and other [4:50] initiative we initiatives we've been [4:52] involved in to basically accelerate an [4:55] idea and actually put it into a real [4:57] operating system to show that it [4:58] actually works and then other people [5:00] could take the code I mean that's right [5:03] that's just continuing in the footsteps [5:05] of csrg so I'm [5:12] happy I think we're getting older and [5:14] we're not as Angry Anymore okay right [5:18] because that's what a lot of the early [5:19] songs were about they were actually [5:21] about a confrontation we had about [5:23] opening up documentation for chipsets or [5:26] uh a bad thing that iatf was doing by [5:30] uh allowing patents to constrain [5:33] protocols or something like that we [5:34] always had a commentary and for the last [5:37] couple of years we haven't had many [5:39] commentaries we've just puttered along [5:41] and kept doing what we [5:48] do it's becoming [5:52] um things have gotten a fairly [5:55] interesting um we don't have a lot of [5:57] new devices showing up um everything is [5:59] becoming very homogeneous uh pretty much [6:02] Intel owns the game now so we actually [6:06] now have more challenges dealing with [6:08] new Intel ethernet chipsets and Intel [6:10] Wireless chipsets than we do with all [6:12] the rest of the other devices they don't [6:13] show up there are no other network [6:15] ethernet chipset showing up from any of [6:17] the vendors at the regular gigabit uh [6:19] space uh it's it's a very um it's it's [6:24] almost a monopoly so it's easier in that [6:26] respect still there are many many other [6:28] challenges to meet for example we have [6:30] not really um met the S&P challenge very [6:33] well yet we still have lots of problems [6:34] over there um and we haven't done [6:36] anything about dealing with uh modern [6:39] x86 VMS and we should probably take a [6:42] take a shot at doing something there as [6:44] well uh we're used to leading in this [6:46] case we may actually be following a [6:48] little bit more we Face a different [6:49] challenge than the other projects [6:51] FreeBSD pretty much only has to care [6:53] about one or two architectures and [6:55] they're very similar to each other we're [6:56] trying to make sure that we keep on [6:58] running on all of our old Legacy [6:59] architectures because we still find [7:00] benefit from them they allow us to [7:03] actually um we find a bug on spark 64 [7:06] because it has certain characteristics [7:08] or we find it on a myip processor or we [7:10] find it on the alpha and we still find [7:12] tremendous benefits from from [7:17] that no it's not worth it it's not worth [7:20] it so we hope that enough people find [7:22] find this a a path so they so they can [7:24] fund us um because the other approaches [7:27] of just asking for people to fund us so [7:29] we can keep doing what we're doing those [7:31] approaches are not working all that well [7:33] I mean we don't have large sponsors [7:34] coming from anywhere we're not like like [7:37] the like the Linux Foundation or like [7:39] the FreeBSD Foundation uh we we don't [7:41] have this large resource Spas uh so [7:45] that's the best this is uh what we [7:47] started doing years and years ago and we [7:49] hope I mean we we understand that almost [7:51] everybody's buying our it's fun it's fun [7:54] and and uh I have I have visited uh [7:56] users in in cities around the world and [7:59] seen uh shell seen their shelves full of [8:01] their discs and how proud they are to [8:03] have almost a full set except for [8:05] missing 2.5 which we didn't make enough [8:12] of I think this is a challenge that the [8:14] operat system without mitigations have [8:16] to ask themselves about because they're [8:18] completely vulnerable to this when these [8:20] applications have these problems but if [8:22] they had these mitigations in their [8:24] systems at least they they would raise [8:25] the bar and make them very difficult [8:28] like [8:30] I I I'm happy that that that we at least [8:34] have mitigations I don't know if this if [8:36] if it's if it's a a full answer MH to [8:39] the problem uh I was there when when [8:42] full when all the full disclosure was [8:44] happening on bug track back in those [8:46] days I knew all of those people at Loft [8:48] and all that they they and cor SDI they [8:50] were they were friends of mine I I was [8:52] involved in in the in the discussions [8:55] this is when the auditing of the open [8:56] BSD tree started in Earnest um [9:00] I it's it's sad the way that it has gone [9:04] um but you can kind of also see where it [9:05] has come from Unix is now mainstream [9:08] it's in every single product that we use [9:10] it has taken over the ecosystem [9:15] uh [9:21] yeah well I think we're more sort of a [9:24] research space um somebody has to do the [9:27] Innovation and push things into the [9:29] ecosystem quickly and tried to get a [9:31] large enough install base so we can [9:33] actually learn which things work and how [9:35] they need to be changed I'll give an [9:37] example um when we were working on our [9:39] ad space randomization and our Malo [9:41] randomization both of them actually ran [9:44] into into this a similar problem which [9:46] is that for example our Adder space [9:48] randomization was too greedy with going [9:50] in add and randomizing the adder space [9:52] too much as a result it was actually [9:54] starting to put pressure on the page [9:55] tables starting to put pressure onto the [9:57] cache starting to put pressure onto the [9:59] soft tables that manage the processes [10:01] virtual address base management so the [10:04] the the data structures were getting [10:05] very very large unnecessarily large [10:07] compared to a system which is a flat map [10:10] with no randomization same sort of thing [10:12] happened in our malok in the maok we we [10:15] we started adding guard Pages all over [10:17] the place and we had to back down [10:19] because we discovered that real world [10:20] software out there is not ready for this [10:22] there's too many bugs in the software [10:24] and and our ports developers were very [10:26] unhappy with the situation stuff just [10:28] wasn't running running longterm so we [10:30] had to back off the guard paging and do [10:33] a something that that's less less less [10:35] guarded memory and we hope that in time [10:38] we some of the developers will once in a [10:40] while turn on that feature because it's [10:41] a way to turn it on on PR program to [10:44] program and if we push that up the [10:46] ecosystem maybe we can actually see some [10:48] improvements down in the long term but [10:50] not in the short term so we wouldn't [10:52] have learned that if we had actually [10:53] thrown it out to our community and the [10:55] only way to throw it out to our [10:56] community is to actually go and throw it [10:58] in throw away backwards compatibility [11:00] usually we it's not terribly harsh uh [11:03] and we have a community here that's [11:04] accepting of this they they see the path [11:06] forward they know that that that uh they [11:09] know that not every single change that [11:11] comes and braks back compatibility is [11:13] directly suited for them and directly [11:16] targeted to them but they know that some [11:17] of the other ones are and so it's a give [11:20] and take sort of inside our user [11:22] community and our development community [11:29] uh there has to be sort of in our six [11:31] month cycle there has to be a period of [11:33] time when lots of people run the same [11:34] code so that if we've made a [11:37] mistake um if we kind of Mis misjudged [11:41] the impact of one of our changes that's [11:43] the time when we're really going to find [11:45] out and people are going to deploy that [11:46] code and run with it and it's going to [11:48] work out fine these are these are small [11:50] little effects but we need to we need to [11:51] learn from our users [11:59] the primary thing that happens in our [12:01] project is that the developers who make [12:03] those changes have to want to make those [12:05] changes they have to have an itch they [12:06] want to [12:08] scratch so I don't know what the future [12:11] road map is I know what I know the [12:13] things that bother me that I think we [12:14] should improve and I know some of the [12:16] other developers what they want to [12:18] improve but I'm not going to make any [12:20] promis about what's going to come in SNP [12:22] or what's going to come in improvements [12:24] for for Network performance uh I can [12:28] promise it's going to be more [12:30] backwards compatibility breaks in the [12:32] future but they'll be small small [12:34] compared to the recent 64 but time [12:37] change [12:42] um oh it's a tremendous it it was it's a [12:45] really large change there's a there's [12:47] many ways of actually dealing with 64 [12:49] but time in theory you can go find web [12:52] pages that people have come up with [12:53] prototypes but no one's actually pushed [12:55] it all the way into an operating system [12:57] and thought of all the logistics of how [12:59] you're going to get all the application [13:00] programmers to use a new API so instead [13:03] we went with with just changing the type [13:06] at the at a very very low level and it's [13:09] really interesting because we now have [13:10] application we art ports Tre runs on it [13:14] so we're basically dragging the entire [13:16] application base along with openbsd so [13:19] that by the time we get to the point [13:21] where anybody else wants to actually [13:22] switch to 64 B time the application [13:24] space will be ready for them and that's [13:26] similar to what we did with all of our [13:28] exploit mitigation and address bace [13:29] randomization features by deploying them [13:31] in a real system and dragging the [13:33] application space towards it anybody [13:35] tomorrow in their operating system can [13:36] turn these things on by default they [13:38] don't have to worry Milla is going to [13:39] work we've made sure of that