Why OpenBSD stands alone

As the Fedora Secureblue developers themselves say:

Secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop. We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you.

• Linux is limited, and it will never be truly secure in its current model. It was not built for that goal.

0 - Philosophy

OpenBSD believes in strong security. Our aspiration is to be NUMBER ONE in the industry for security (if we are not already there). Our open software development model permits us to take a more uncompromising view towards increased security than most vendors are able to. We can make changes the vendors would not make.

• This is different from most operating systems, which were not created with the goal of being the most secure. The Linux kernel was not designed around extreme security from the beginning, and old design choices still affect it. A few Linux distributions aim for security, but they do not rewrite the operating system from scratch; they mostly harden user space and parts of the kernel. That is useful, but it does not match OpenBSD, or the BSD family in general.

1 - Library order randomization

In rc(8), libc.so, libcrypto, and ld.so are relinked on startup, so their objects are placed in a random order at boot. This makes return-oriented programming and similar attacks harder, because symbol locations are no longer predictable in the same way.

• Linux randomizes base addresses, but it does not relink or reorder internal libc symbols at each boot. Internal offsets and gadgets in the same build can remain predictable across machines or boots, so a small infoleak can be enough to locate useful gadgets.

2 - arc4random(3)

OpenBSD has its own cryptographic random number interface. When random input is needed, arc4random is the standard choice. It is an abstraction over ciphers considered safe today, currently using ChaCha20. The name means "A Replacement Call for Random," and it quickly generates high-quality 32-bit pseudorandom numbers.

3 - First in security implementations

• The first operating system to integrate post-quantum encryption by default (since April 2022, OpenSSH).
• The first widely used operating system to provide ASLR by default.
• The first free operating system to provide an IPSec stack.
• The first widely used operating system to enable PIE globally by default.
• The first operating system to enable stack protector system-wide by default.
• First complete integration and adoption of IPv6, starting Jan 6, 1999. Almost fully operational Jun 6, 1999 during the first OpenBSD hackathon.

With OpenBSD, you consistently get major security implementations earlier than on other operating systems.

4 - Camera and audio recording

For privacy reasons, the OpenBSD team disabled camera and audio recording for all devices by default in the kernel. This can be toggled on and off with a simple sysctl change, without rebooting.

5 - Chrooted web server by default

By default, HTTP daemons are chrooted in /var/www. As an OpenBSD system administrator, you do not need extra setup to run a secure web server installation. This is also true for HTTP daemons from packages (apache2, nginx).

6 - cron(8)

OpenBSD's cron(8) daemon can randomize values (~) and prevent multiple jobs from running concurrently (-s). Preventing conflicts avoids race conditions, simultaneous access to shared resources, and overload caused by multiple instances, reducing the risk of data corruption and load spikes. Randomization reduces synchronized peaks (the thundering herd problem) and makes it difficult for attackers to predict execution windows.

• This can be configured in Linux through systemd (strongly opposed to systemd.), but it does not come enabled by default.

6.1 - security(8)

OpenBSD includes security(8), a script run by daily(8) that checks for signs of common security weaknesses and mails any output to root. Its checks cover account databases, root's login environment, home and dotfile permissions, changes to files in /etc/changelist, mounted-disk labels and partition tables, package changes, and selected network configuration permissions.

The manual is careful to call security(8) an aid, not complete protection. It is useful because obvious weaknesses and unexpected changes become part of routine administration, as long as someone reviews the daily reports and maintains the monitored file list.

7 - Defined integer overflows

On OpenBSD, Clang, the default compiler on most architectures, has the -fwrapv flag enabled by default. GCC also does not include -fstrict-overflow in the -O2 optimization option. This tells the compiler to treat signed integer overflows as defined, preventing optimizations that remove security-critical overflow checks. This is another example of sane defaults.

8 - doas(1)

OpenBSD does not use sudo, so it created "doas." doas replaced sudo because of sudo's security flaws and large, complex codebase. doas is easy to configure and use, and it covers most use cases. Its source code is small and elegant.

This is an example of a fully hardened doas.conf configuration:

permit <user> as root
permit root

Compare this with the simplest sudo configuration and you will see the difference.

• Using doas on Linux is possible, although many distributions still have rough edges. Fedora Secureblue removed suid-root, sudo, su, and pkexec to use run0, reinforcing my argument about sudo insecurity.

9 - freezero(3)

The libc function freezero(3) lets programs free memory that holds sensitive data and overwrite it with zeros.

• On Linux you have equivalent APIs, but not by default.

10 - httpd(8)

OpenBSD includes httpd(8) in the base system. It is not based on Apache: it was written from scratch by OpenBSD developers with a small codebase and security-first design.

OpenBSD recently extended relinking hardening to userland network services such as httpd and smtpd. Randomized relinking changes internal object layout across builds and updates, which reduces gadget predictability and raises exploit cost in the same spirit as KARL and library-order randomization. This strengthens OpenBSD's broader model: keep privileged components small, audited, and less predictable to an attacker. See the OpenBSD -current changelog entry "Random-relink smtpd(8) and httpd(8) at boot" and the related OpenBSD community write-up: https://www.openbsd.org/plus.html, https://undeadly.org/cgi?action=article;sid=20260605064136.

10.1 - relayd(8)

relayd(8) is OpenBSD's relay and application-layer proxy daemon. It provides reverse proxying, load balancing, health checks, and TLS handling with a compact configuration model that integrates well with the rest of the base networking stack.

10.2 - smtpd(8)

smtpd(8), from the OpenSMTPD project, is OpenBSD's native mail daemon in base. It was developed by OpenBSD contributors with a focus on simplicity, secure defaults, and robust privilege separation.

11 - KARL

At every install, upgrade, and boot, OpenBSD generates a new kernel with randomized addresses. A unique and unpredictable kernel is a real security improvement. This technique is called Kernel Address Randomized Link (KARL), and combined with library order randomization, it is one of OpenBSD's strongest ideas.

• macOS, Windows, and Linux have KASLR (kernel base address randomization), but not KARL. KARL is the stronger design.

12 - Kernel & Userland

The kernel and userland in OpenBSD, as in the BSD family generally, are developed together. The same project that introduces kernel features also controls the base userland, so new security ideas can be applied consistently across the OS. pledge, unveil, and arc4random are good examples.

• The Linux kernel and the GNU Core Utilities, or musl/BusyBox on non-GNU systems, are developed independently. That makes it much harder to introduce something like pledge, or even a consistent SELinux/AppArmor approach, across all base tools. This lack of unity makes Linux security fragmented. macOS and Windows have more unified development, but they tend to prioritize features and compatibility, especially Windows with its heavy legacy burden.
• Windows, macOS, and BSDs do not have this problem. Linux falls behind here.

13 - LibreSSL

The bloated and difficult OpenSSL codebase was forked after Heartbleed. LibreSSL cleaned up, improved, and documented large parts of that code. It added modern cryptography such as FRP256v1, RFC 5639 EC Brainpool, ChaCha20, and Poly1305, while remaining API-compatible with OpenSSL without carrying the same level of complexity. It is actively developed by OpenBSD developers.

• Nowadays, macOS OpenSSL uses LibreSSL code.

14 - License

You are free to use the operating system however you want, including for business, under ISC or Berkeley-style licenses. By project policy, GPL code is not acceptable for new additions. The BSD license is freer than the GPL, which places more restrictions on code use.

This licensing culture also helps protect the project from corporate capture and internal pressure. Linux has spent years pulled between community goals and large corporate interests, especially from companies such as IBM that want Linux shaped for enterprise platforms. That pressure damages the Unix philosophy.

A license as permissive as BSD allows companies to use, close, distribute, and resell OpenBSD code. I see that freedom as a strength, not a weakness, because it keeps the project simple and avoids the ideological battles that often surround copyleft licensing.

• The Linux and GNU world is built heavily around the GPL. In a perfect world, where open-source programmers and huge companies had aligned incentives, that would be ideal. We do not live in that world. macOS and Windows are proprietary, while OpenBSD is fully open source.

15 - Malloc leak detection

This is a tool the team uses to detect unsafe behavior in OpenBSD code. It requires debug symbols. It tracks memory allocations so they can be properly freed after use, supporting safer native programming in the system.

• Linux, macOS, and Windows have tools in their ecosystems for this, but none are integrated into the operating system by default.

16 - Documentation - manpages

There is probably no operating system documented more thoroughly than OpenBSD. Every binary, library, driver, or script delivered in the base system has its own man page. The OpenBSD project treats missing documentation for any system function as a bug.

• Linux documentation is fragmented by comparison, which leaves many users with major knowledge gaps and leads to configuration errors. That weakens security in practice. Community projects such as the Arch Wiki partly compensate for this gap.

Linux still falls short here.

17 - Meltdown and Spectre

To mitigate Meltdown and Spectre, OpenBSD disables hyper-threading by default, citing security concerns, including Spectre-style concerns, with "a new hw.smt sysctl".

• Besides OpenBSD, Fedora Secureblue is the only OS that does this, inspired by OpenBSD of course.

18 - Memory allocation randomization

All those OSes (Windows, Linux, macOS, Android, etc.) provide malloc implementations, but OpenBSD's malloc is widely regarded as one of the most security‑focused and well‑audited defaults.

• GrapheneOS's hardened_malloc is heavily inspired by OpenBSD's design and offers stronger hardening than typical Linux defaults. Fedora Secureblue uses hardened_malloc globally. But as the GrapheneOS devs themselves said:

  The main differences in the design are that it's solely focused on hardening rather than finding bugs

That is, OpenBSD gains a potential advantage by being less likely to have undiscovered bugs that could become security vulnerabilities.

19 - OpenSMTPD

OpenSMTPD was written from scratch by OpenBSD developers. A simple mail daemon was needed for the base system, and there were no suitable alternatives. The goals are simplicity, security, and reliability under an acceptable license (ISC).

• OpenSMTPD has a portable version available in several Linux distributions, but it is not included by default in any of them.

20 - OpenSSH

The most popular OpenBSD software is probably OpenSSH. It is the SSH standard used worldwide and is native in all BSDs, macOS, and even Windows/Windows Server. From routers and switches to cloud services and hosting, OpenSSH is everywhere, and it has included post-quantum cryptography by default since April 2022.

21 - Firewall

pf is OpenBSD's firewall. It is simple, feature-rich, and easy to read. It supports variables, lists, and tables. Many commercial firewall appliances are based on it.

• Linux's iptables and nftables are extremely complex compared to pf, and that complexity can lead even advanced users into dangerous mistakes. That is why frontends such as firewalld and ufw exist. iptables and nftables have difficult, cumbersome syntax; the existence of full professional certification courses just to learn them says a lot.

• The Windows firewall is weak for advanced control. Users have limited direct control, and most behavior is managed through a restrictive GUI. It can still block malware and unwanted traffic, but it is not pleasant for serious administration.

• I rate the macOS firewall much more positively: it is safe, simple, and user-controlled. It is based on OpenBSD's pf.

• The NetBSD firewall, npf, is also very good. Its syntax is similar to pf, though a little more complex.

• FreeBSD has three firewalls, which is messy, but one of them is pf. FreeBSD's pf has diverged from OpenBSD's pf enough that it feels almost like a fork.

22 - PID randomization

OpenBSD spawns each new process with a random unused PID. This helps protect users from attacks that rely on predicting process IDs.

• Linux kernel allocates PIDs in a semi-sequential (incremental) way, recycling when it reaches pid_max; it does not randomize them by historical design. The same goes for Windows and macOS.

23 - ping randomness

Both ping(8) and ping6(8) obfuscate transmitted monotonic clock values by offsetting them with a random value. ChaCha streams vary each payload. This helps hide system time from attackers and makes OS detection harder.

• Neither Windows, Linux, nor macOS has this.

24 - pledge

pledge lets a program limit its own access to system calls with very little code. That is a huge security improvement. Even if a binary is compromised, its ability to misbehave is sharply reduced. Within only two releases, OpenBSD developers introduced pledge across most base system binaries. Today, all base system binaries must be pledged.

• Linux has seccomp, which can emulate pledge's syscall‑restriction part, but seccomp is low-level, hard to write correctly by hand, and brittle across libc/kernel behavior changes and needs tools (like libseccomp) to avoid mistakes; writing policies for this is error‑prone.
• I do not consider seccomp practically usable for ordinary hardening, and this critique explains why: https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.html
• Windows has no direct pledge analogue. macOS has sandbox_init / Seatbelt, more integrated for GUI apps but more complex for arbitrary CLI programs.

25 - unveil

The unveil system call limits filesystem open calls to a defined set of paths. It extends the idea of pledge: simply limiting programs to open is insufficient, because open is valid for the whole filesystem.

For example, why should a program like passwd(1) have access to your file system beyond /etc/passwd and /etc/shadow? If there is a security bug in passwd, the effects would be more limited.

Browsers such as Firefox, Firefox ESR, Tor Browser, Chromium, and Iridium are limited with unveil and pledge. They can access the Downloads folder and their own system folders, but not arbitrary files elsewhere. That turns the browser into a much tighter container for malware.

• Linux Landlock, AppArmor, SELinux, Smack: filesystem and broader MAC policies can restrict file access like unveil, but configured externally and with a lot of additional complexity, being disabled or misconfigured in all Linux distros besides Secureblue and Android (debatable, perhaps none of them). Linux has no single, simple process‑centric API combining easy syscall profiles + builtin per‑process filesystem veil like pledge+unveil. Such complexity, something common in the Linux world, only leads to more insecurity.
• Windows has no direct unveil analogue, nor does macOS.

26 - Privilege and user separation

OpenBSD runs all of the standard base system daemons with privilege and user separation. These include for example bgpd(8), dhclient(8), dhcpd(8), dvmrpd(8), eigrpd(8), file(1), httpd(8), iked(8), ldapd(8), ldpd(8), mountd(8), npppd(8), ntpd(8), ospfd(8), ospf6d(8), pflogd(8), radiusd(8), relayd(8), ripd(8), script(1), smtpd(8), syslogd(8), tcpdump(8), tmux(1), xconsole(1), xdm(1), X server(1), ypldap(8), pkg_add(1), etc.

• All major OSes support privilege separation and many core services run with reduced privileges, but OpenBSD applies it much more uniformly and as a central design principle for its base system. Linux/macOS/Windows have many tools, but they are all extremely complex and require extra configuration, per‑service work, or policy management.
• A lot of complexity only leads to more problems. In theory, Windows has much stronger privilege separation than Linux and macOS, but it has never proven to be functional and reliable; on the contrary.
• No Linux other than Secureblue and GrapheneOS have good configurations, Linux has many tools but no one uses them because of such complexity

27 - Privilege revocation

Related to the work on privilege separation, some programs were refactored to drop privileges while holding onto a tricky resource such as a raw socket, reserved port, or modification-locked bpf(4) descriptor, for example ping(8), traceroute(8), etc.

• Linux tried to implement this, but it never worked; it is complex and is never enabled by default in any distro other than Secureblue. macOS doesn't seem to have it, and on Windows it's definitely useless.

28 - MAC addresses randomized

OpenBSD lets you use randomized MAC addresses via ifconfig.

ifconfig iwm0 lladdr random

Randomizing your MAC address improves anonymity while using your laptop in public Wi-Fi or similar networks.

• Fedora Secureblue, QubesOS (per NetVM) and Tails have this, Whonix and others don't.

29 - rcctl(8)

rcctl is a simple utility for maintaining rc.conf.local, OpenBSD's system daemon configuration database. Compared with systemd or SysVinit, I find rcctl lighter, more stable, more secure, and easier to understand. Systemd, by contrast, behaves almost like a full operating system, with substantial Red Hat-driven complexity.

• Gentoo and distributions such as Artix, Alpine, and Void have the advantage of avoiding systemd, or SysVinit in some cases. But Qubes OS, Fedora Secureblue, Tails, Whonix, Kicksecure, Arch, NixOS, and many others use it.

30 - recallocarray(3)

recallocarray is a libc function that discards old data before allocating new memory and checks for integer overflow in multiplication.

• Linux, Windows, and macOS: No.

31 - rpki-client(8)

The rpki-client utility queries the RPKI repository system with openrsync to fetch all X.509 certificates, manifests, and revocation lists under a given Trust Anchor. rpki-client subsequently validates each Route Origin Authorization (ROA) by constructing and verifying a certification path for the certificate associated with the ROA (including checking relevant CRLs). rpki-client produces lists of the Validated ROA Payloads (VRPs) in various formats.

• This is an OpenBSD feature. It is available for installation on Linux and macOS, although no Linux distro uses it by default.

32 - Sane & secure defaults

OpenBSD ships with sane, secure defaults in daemons and configurations.

The system is intended to be secure by default, and many of its security features are either missing or optional in other operating systems.

This means you do not have to harden a fresh installation just to run basic services. For example, sshd does not require an extra hardening phase. The same is true for other daemons and base-system components.

• That is the worst aspect of Linux. Every distribution needs a lot of extra security to be minimally secure enough for you to sleep peacefully. Except for Fedora Secureblue, which already comes with enhanced security by default, although at a much lower level than OpenBSD. Furthermore, hardening done by the average, unprepared user can (and probably will) lead to many problems and perhaps even more security breaches.
• A secure system by default is necessary, and in the Linux world, Secureblue is the only example of this. There's also GrapheneOS, which is a Linux distribution (although many deny that Android is Linux).

33 - signify(1)

signify is a small, elegant tool for cryptographically signing and verifying files. It was created to sign OpenBSD releases (since OpenBSD 5.5) and binary patches for syspatch. It uses only Ed25519. Think of it as a simpler replacement for PGP signing.

The same applies to packages: when a package is signed, pkg_add uses the appropriate key in /etc/signify to verify the signature and only unpacks/installs if the verification and checksums match. This makes it impossible to download a compromised version of OpenBSD or its binaries, even if the official repository is compromised by the NSA.

• Linux has GnuPG/OpenPGP. But signify has a more defensive position against common attack modes in GnuPG/OpenPGP, such as a lower likelihood of confusion involving multiple keys, subkeys, expired certificates, and legacy formats. Ed25519 also has an API and resistance to usage errors that are better than those of the historical OpenPGP ecosystem. Fedora is the best distro in this regard; it handles OpenPGP well.
• GnuPG/OpenPGP is large and complex; signify is simple and secure by default on OpenBSD.
• Signify is available for installation on Linux and macOS.

34 - Stack

Aggressive randomisation of the stack location since version 7.3 (2023), this will put the stack at a random location in the upper 1/4th of the userland virtual address space providing up to 26 additional bits of randomness in the address. This aggressive randomisation of the stack location is for all 64-bit architectures except alpha. This should make it harder for an attacker to find the stack.

• It is possible, through patches like PaX/grsecurity, to reinforce the security of the Linux kernel in this regard, but this requires manual intervention and is not like in OpenBSD, not even by default (does Fedora Secureblue have something like that? I know they use a hardened Linux kernel).

35 - stack-register checking

A memory object should have the fewest permissions possible: typically read, write and execute. OpenBSD introduced a new permission flag known as stack. If you want to use memory as a stack, you must mmap it with that flag bit. When a system call happens, we check to see if the stack-pointer register points to such a page. If not, the program is killed. The ABI is tighter as a result. You may no longer point your stack register at non-stack memory, or your program will die.

• macOS, Windows, and Linux: No.

36 - Swap encryption by default

This protects sensitive information, such as passwords, from leaking to disk where it can persist for years.

• Linux supports this (it must be done manually), but only Fedora Secureblue has by default.
• GrapheneOS seems to have that, but it's more dynamic.
• macOS swap and sleep image are encrypted when FileVault (full-disk encryption) is enabled. I rate Windows BitLocker poorly for reliability.

37 - Syscall origin verification

The kernel checks whether a syscall is executed from the address space of its corresponding process. If not, the process is killed. This helps prevent attackers from using uploaded exploit code with raw system call sequences.

• Linux, Windows, and macOS: No.

38 - unwind(8) validating DNS resolver

unwind is a validating DNS resolver. It is designed for client machines such as workstations or laptops and listens only on localhost. It queries nameservers directly and switches to resolvers learned from dhclient(8) if local networks block DNS queries. It periodically checks whether DNS is still blocked and switches back when possible. I use it to maximize privacy by keeping DNS resolution local.

• Fedora Secureblue uses unbound which also comes by default in OpenBSD, but is more complex and unnecessary in most cases, a simple unwind configuration may require several lines in unbound.

39 - W^X Memory

Since 2003, memory on OpenBSD can be writable or executable, but not both. This is a major security feature that helps prevent attackers from executing injected payloads through memory-corruption bugs.

• Linux, Windows, and macOS don't have this as a global kernel policy; some Linux distributions and architectures apply NX/UEP and mitigations, but W^X by process is not enforced as in OpenBSD.

40 - WireGuard

OpenBSD has an in-kernel driver for WireGuard VPN communication. Including WireGuard in the kernel improves performance and makes it easy to use from the OpenBSD base system.

WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography.

With this, you can do a base offline installation of OpenBSD and set up a good VPN such as Mullvad or IVPN right away. Both officially support WireGuard.

• WireGuard is integrated into the OpenBSD kernel. Linux, Windows, and macOS have WireGuard support, but not in this OpenBSD-style base system form.

41 - file(1)

file(1) is sandboxed and runs as the _file user. Imagine downloading a random file from the internet and analyzing it with file. If file had a local code execution bug and the downloaded file was crafted to exploit it, that bug could become dangerous. OpenBSD reduces this risk by sandboxing and chrooting the utility by default.

• This is something unique to OpenBSD.

42 - vmm(4) - hardened hypervisor

Theo de Raadt has long criticized virtual machines and their security model, arguing that the hypervisor is often the weakest and easiest point to exploit. OpenBSD still created its own hypervisor, but with a focus on security and a small attack surface rather than feature count. That means losing many VM features, including:

• Graphics
• Snapshots
• Guest SMP support
• Hardware passthrough
• Live migration across hosts
• Live hardware change

Supported guest operating systems are currently limited to OpenBSD and Linux. Because there is no VGA support yet, the guest OS must support a serial console. A graphical interface is still possible with tools such as Xephyr, and probably with vncviewer or Proxmox-style setups.

• QEMU/KVM, Xen, Hyper-V, VMware, VirtualBox, and other hypervisors were not built from scratch with security as the first priority. VM management can also be weakened by the surrounding operating system, including components such as systemd.
• Hardware passthrough greatly increases the attack surface. Additional hardware technology (such as IOMMU) is required for minimum security.

43 - X server without root permissions and xenodm: the secure X Display manager

OpenBSD developers have worked hard to enable the non-root execution of an X server. Since 2014, X no longer requires special privileges and can be run as a regular user rather than root. OpenBSD has its own soft fork of the X.Org server called Xenocara, designed to enhance security. In addition, Xorg's internet access is blocked by default by the firewall pf.

Xenodm is a simplified fork of xdm: lightweight, more secure, and stripped of XDMCP support because of many security vulnerabilities. It supports only the BSDauth code used in OpenBSD. On OpenBSD, xenodm is absolutely necessary to start the X server, because it no longer has setuid rights enabled by default.

• The standard X11/Xorg stack is legacy-heavy, vulnerability-prone, and full of historical baggage. Xenocara is a major improvement in OpenBSD. XLibre is a later effort in a similar direction, but it does not match Xenocara's security profile.

Wayland is much more secure than X11, but it has still had serious vulnerabilities, and XWayland exists for compatibility with older software. Fedora Secureblue disables XWayland globally for this reason. Wayland is not automatically safe, and its sandboxing can be weakened by compositors such as Hyprland, which Secureblue does not recommend. XLibre and Xenocara are better directions, though only XLibre is usable on Linux.

44 - No proprietary blobs

OpenBSD has a project policy of avoiding non-free blobs and firmware in the system.

• Linux kernel includes many binary blobs; the absence of this is only possible in Linux-libre distros, like Hyperbola, Trisquel, and Parabola.
• Windows and macOS are proprietary software.
• Other BSDs like NetBSD and FreeBSD also have the advantage of not having proprietary blobs by default, but installation is possible.

45 - RETGUARD

RETGUARD is a replacement for the stack protector that uses a per-function random cookie (located in the read-only ELF .openbsd.randomdata section) to consistency-check the return address on the stack. Implemented for amd64 and arm64 by Todd Mortimer in OpenBSD 6.4, for mips64 in OpenBSD 6.7, and powerpc/powerpc64 in OpenBSD 6.9. amd64 system call stubs also protected in OpenBSD 7.3.

• Linux and macOS: No.
• Windows utilizes CFG, DEP/NX, Control Flow Application Technology (CET) support on newer CPUs (hardware shadow stacks), and SEH/unwind metadata. Hardware shadow stacks (Intel CET) offer more robust backward protection and are a closer analogue to RETGUARD's XOR cookies.

46 - Audit Process

https://www.openbsd.org/security.html

The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component. We are not so much looking for security holes, as we are looking for basic software bugs, and if years later someone discovers the problem used to be a security issue, and we fixed it because it was just a bug, well, all the better. Flaws have been found in just about every area of the system. Entire new classes of security problems have been found during our audit, and often source code which had been audited earlier needs re-auditing with these new flaws in mind. Code often gets audited multiple times, and by multiple people with different auditing skills.

Some members of our security auditing team worked for Secure Networks, the company that made the industry's premier network security scanning software package Ballista (Secure Networks got purchased by Network Associates, Ballista got renamed to Cybercop Scanner, and well…) That company did a lot of security research, and thus fit in well with the OpenBSD stance. OpenBSD passed Ballista's tests with flying colours since day 1.

Another facet of our security auditing process is its proactiveness. In most cases we have found that the determination of exploitability is not an issue. During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable. (Or, more likely someone on BUGTRAQ would report that other operating systems were vulnerable to a newly discovered problem, and then it would be discovered that OpenBSD had been fixed in a previous release). In other cases we have been saved from full exploitability of complex step-by-step attacks because we had fixed one of the intermediate steps. An example of where we managed such a success is the lpd advisory that Secure Networks put out.

47 - Project Goals

OpenBSD's goals are clear, precise, and they greatly increase user confidence.

https://www.openbsd.org/goals.html

1. Provide the best development platform possible. Provide full source access to developers and users, including the ability to look at CVS tree changes directly. Users can even look at our source tree and changes directly on the web!

2. Integrate good code from any source with acceptable licenses. ISC or Berkeley style licences are preferred, the GPL is not acceptable when adding new code, NDAs are never acceptable. We want to make available source code that anyone can use for ANY PURPOSE, with no restrictions. We strive to make our software robust and secure, and encourage companies to use whichever pieces they want to. There are commercial spin-offs of OpenBSD.

3. Pay attention to security problems and fix them before anyone else does. (Try to be the #1 most secure operating system.)

4. Greater integration of cryptographic software. OpenBSD is developed and released from Canada and due to Canadian law it is legal to export crypto to the world (as researched by a Canadian individual and as documented in the Export Control list of Canada).

5. Track and implement standards (ANSI, POSIX, parts of X/Open, etc.)

6. Work towards a very machine independent source tree. Support as many different systems and hardware as feasible.

7. Be as politics-free as possible; solutions should be decided on the basis of technical merit.

8. Focus on being developer-oriented in all senses, including holding developer-only events called hackathons.

9. Do not let serious problems sit unsolved.

10. Make a release approximately every six months.

This makes OpenBSD predictable, reliable, stable, and verifiable, which in turn strengthens security.

• Linux development is chaotic, as I argued in topic 12. Big changes happen constantly, and the project is highly malleable under pressure from large corporations such as IBM, partly because of the GPL-centered ecosystem around it.
• Windows has always been messy, and each version adds more complexity. At least Microsoft's target is clear: the average desktop user. Windows can be pleasant for that audience, especially for people who do not care much about performance.
• macOS is pretty predictable. Nothing changes and Apple products only become more and more expensive.
• NetBSD and FreeBSD also have clear goals, although almost completely different from OpenBSD.

48 - Politics-free

Be as politics-free as possible; solutions should be decided on the basis of technical merit.

OpenBSD development is intentionally kept separate from politics and social causes. The developers, especially Theo de Raadt, tend to make decisions based on technical merit rather than public pressure.

One of the many (hundreds) examples of this was when an OpenBSD user proposed a change of term in the OS code, claiming that the term was sexist against women and was "pretty offensive": https://marc.info/?l=openbsd-advocacy&m=175975971608913&w=2

But OpenBSD creator Theo de Raadt responded: https://marc.info/?l=openbsd-advocacy&m=175977519419628&w=2

OpenBSD has proven reliable in this regard. Unlike many other operating systems, it has resisted political and social pressure inside its technical decision-making.

• Linux, by contrast, often tries to satisfy social expectations before focusing on software efficiency and security. Vanity and public approval sometimes matter too much in the Linux world, while old bugs and structural problems remain unresolved.

  One example is the merge of inclusive-terminology rules into the Linux kernel tree, aimed at replacing terms such as "master", "slave", "blacklist", and "whitelist" that programmers had used for decades: https://linuxreviews.org/Linus_Torvalds_Has_Merged_Inclusive-Terminology_Rules_Into_The_Linux_Kernel_Git_Tree

• None of these changes improves code efficiency. My criticism is that effort should go first toward long-standing kernel bugs and vulnerabilities instead of terminology updates. I see this as one example of a broader priority problem in Linux development.

• Beyond the kernel, the Linux world has cases like systemd "detect-fash":

  • https://github.com/systemd/systemd/pull/39285/files#diff-b7bd9ee11c7f9765af38ea0fef669628945f07a131571d95a1b3b67c19d17ade
  • https://forums.theregister.com/forum/all/2025/10/14/framework_linux_controversy/

The most disturbing part is that many people supported the commit. To me, this shows how quickly a political or social idea can appear in the Linux world and create risk for specific users. If maintainers decide that a group is "problematic" and should be treated differently, a harmful feature can appear very quickly. That makes it hard to trust the ecosystem calmly.

OpenBSD is different. As mentioned in topic 12, the kernel and userland are developed together, which greatly reduces the chance of this kind of surprise entering the system.

• Windows and macOS also try to please broad audiences rather than focusing purely on software efficiency. That is understandable for proprietary, paid operating systems. I expect it there; I do not want it in Linux.

• FreeBSD is becoming worse in this regard. The community is changing, which is not necessarily a problem as long as those pressures stay out of OS development.

• NetBSD and DragonFlyBSD don't seem to suffer from this type of problem, but I don't really know.

49 - Less attack surface

As of 2026-02-16, the entire OpenBSD operating system (src + xenocara) has 35,590,098 lines of code. The OpenBSD kernel (src/sys) has a total of 7,906,769 lines of code.

Is that a lot? Yes. Is it too much? In my view, yes. But compare it with alternatives:

• The Linux kernel alone has more than 40 million lines of code: https://commandlinux.com/statistics/Linux-kernel-contributors-lines-of-code-statistics/
• Debian 7.0 in 2012 had 419 million lines of code: https://en.wikipedia.org/wiki/Source_lines_of_code#Example Currently it must have surpassed the billion LoC: https://sources.debian.org/stats/#sloc_current

Windows is likely beyond one billion lines, and probably macOS as well. FreeBSD and NetBSD have more lines of code than OpenBSD, but most likely less than the Linux kernel or a Linux distro.

More lines of code mean more attack surface, more bugs, and more vulnerabilities. OpenBSD's philosophy focuses on minimalism and security. Its developers understand that clean, minimal code lowers attack surface, and they actively follow that approach.

With any Linux distribution, even Gentoo or Linux from Scratch, you are dealing with tens or hundreds of millions of lines of code, perhaps more depending on the full system. That is an incomparably larger attack surface than OpenBSD. The Linux kernel alone is larger than the entire OpenBSD operating system. Windows 10 and 11 are even harder to judge, because only Microsoft knows how much proprietary code is involved.

With OpenBSD, you start with a smaller attack surface than most other monolithic or hybrid-kernel operating systems. That improves user security and also makes additional mitigations easier to implement. Maintenance becomes easier, code quality improves, and reliability improves with it. From a security and reliability perspective, I see no downside.

Even the official OpenBSD websites have a low amount of code: 312,465 lines in total as of 2026-02-26. That improves privacy and user experience beyond the operating system itself. Microsoft, Apple, and many Linux distribution websites are heavy, JavaScript-filled, and telemetry-friendly by comparison.