Learn OpenBSD - Core Concepts & Main Architecture

#Introduction

In episode 1 you understood the history and the secure by default philosophy that animate OpenBSD. Now it's time to break down the architecture — how this system is structured so that philosophy can be put into practice. After this episode, you'll know why OpenBSD feels "clean" and easy to understand compared to other systems that pile on layer after layer.

The OpenBSD architecture can be summarized in one sentence: a complete, battle-tested base system is sharply separated from third-party packages, with a kernel and userland designed to complement each other for security.

#Core Concepts & Main Architecture

Before diving into each component one by one, it's worth locking in three core concepts that form the backbone of the OpenBSD architecture:

• Base system vs packages: the core system audited by the OpenBSD team is sharply separated from third-party applications. These two worlds have different trust levels, and the boundary between them is always maintained.
• Release, snapshot, and -current: the three-track development model determines where you pull code from — from the stable release used in production to the development branch for testers and bug hunters.
• A kernel with KARL and KASLR: memory corruption mitigations are active from boot; the kernel is randomly relinked on every reboot so its memory layout cannot be predicted by an attacker.

These three concepts will reappear in almost every episode of this series. Understanding them early makes commands that look technical feel like a logical continuation of one design, not just a bag of tricks.

#Base System vs Packages

The concept that most sets OpenBSD apart from most Linux distributions is the sharp division between two worlds:

• Base system: the kernel + userland + core utilities managed by the OpenBSD team itself. This includes sh, ksh, vi, the C compiler, pf, OpenSSH, LibreSSL, and everything the system needs to live. The base system is installed from file sets like base74.tgz and updated via sysupgrade or syspatch.
• Packages: third-party applications (nginx, postgresql, etc.) compiled from ports. Installed with pkg_add into /usr/local, separate from the base system.

This separation matters both for security and operations. The base system is trusted and audited; packages are third-party code living in a "user" environment. You can see the boundary with pkg_info — installed packages are reported there, not in the base system.

#Release, Snapshot, and -current

OpenBSD uses a clear development model:

The choice between -release/-stable and -current will be covered in depth in episode 20. For now, remember: production uses -stable, and syspatch is the official mechanism for security patches without changing the release version.

#Kernel: The Heart of OpenBSD

The OpenBSD kernel is monolithic yet designed with modern security practices. Some features worth knowing from the start:

• rthreads: a kernel with mature threading and SMP (symmetric multiprocessing) support — the foundation of modern performance.
• KARL (Kernel Address Randomization Link): on every reboot, the kernel is relinked so its internal addresses change randomly. This makes exploiting kernel bugs far harder because the attacker doesn't know its memory layout.
• W^X: memory is never writable and executable at the same time, blocking many attack classes.
• Randomization of the stack, heap, and PIE (position-independent executable).

Check the running kernel configuration with sysctl kern.osrelease and look at security parameters with sysctl kern. Hardening details are covered in episode 15.

#KARL and KASLR

KARL (Kernel Address Randomized Link) is OpenBSD's answer to kernel ASLR (KASLR). On every boot, the kernel is relinked in a random order by reorder_kernel, so the layout of its symbols, functions, and data structures changes every time the system is turned on. As a result, exploitation techniques that rely on fixed addresses inside the kernel lose their footing — an attacker cannot predict where important functions live.

Compare this with ASLR in userland processes: every program is loaded at a random address each time it runs. Combined, the two make OpenBSD's memory layer hard to map from the outside. You can prove KARL's effect directly by comparing the kernel hash before and after a reboot:

sha256 /bsd
ls -l /bsd

Note the hash from sha256 /bsd, then reboot your machine. After the reboot, the hash will be different — proof that the running kernel is the result of a relink that changed from the previous boot.

#A Battle-Tested Userland

Above the kernel is the userland: the programs you interact with every day — shells, compilers, utilities, daemons. What makes the OpenBSD userland special is that it's managed directly by the same team as the kernel, with one code standard and one style. There is no "third-party ecosystem" inside the base system; everything is one unit that is updated, audited, and released together. This is what makes OpenBSD feel so coherent compared to systems that stitch together thousands of different projects.

#Key Base System Components

A single default installation already brings a complete server ecosystem. Here's a map of the components you'll learn about in this series:

Nothing needs to be installed to run basic services — this is one of OpenBSD's advantages.

#Syscall Sandboxing: pledge and unveil

Two of the most iconic features of OpenBSD are its userland sandboxing mechanisms:

• pledge(2): a process can "promise" which syscalls it will use. Once the promise is made, syscalls outside of it are quickly rejected. Example: pledge("stdio rpath", NULL) means the process may only use standard I/O and read files.
• unveil(2): a process restricts filesystem access — only unveiled paths can be accessed, and only with the permissions granted (read, write, execute).

Both will be covered practically in episode 15. What to understand now: every serious program on OpenBSD is expected to use pledge and unveil, including many programs in the base system.

#Why This Architecture Helps You Learn

The sharp separation between base system and packages, plus the consistency across components, makes OpenBSD very easy to learn. When you learn rcctl for one service, you know all other services follow the same pattern. When you learn the configuration of one daemon, its format is similar to the others. This recurring pattern is what accelerates mastery: once you understand the logic, the rest is just following along.

#How It All Connects

Imagine the flow of a request to an OpenBSD web server. Traffic arrives through the network interface, is checked by pf with a strict ruleset, served by httpd which is already pledged and unveiled, communicates via LibreSSL for TLS, and is monitored through syslog logs rotated by newsyslog. Behind it, sshd only accepts ed25519 keys, and every administrative command passes through a logged doas.

All these layers work together without a mandatory third party. This is the architecture that lets OpenBSD promise security out of the box.

Verify the components running on your system:

uname -r
sysctl kern.syncdelay
ls /etc/rc.d

#Closing

In episode 2 you understood the architectural thinking of OpenBSD: a complete base system sharply separated from packages, a clear release/stability/current model, a kernel with modern mitigations like KARL and W^X, and a built-in tooling ecosystem that complements each other.

Key takeaways:

• The base system and packages are two separate worlds; packages live in /usr/local.
• Production uses -release/-stable, not -current.
• The kernel applies proactive mitigations: KARL, W^X, and memory randomization.
• pf, OpenSSH, LibreSSL, httpd, relayd, OpenSMTPD, and tmux are already in the base system.

In the next episode, episode 3, we'll install OpenBSD and create partitions — step by step through the installer, understanding file sets, fdisk with GPT, disklabel, the FFS2 filesystem, and swap. Make sure the VM from episode 0 is ready to boot!