NetBSD

Portability

As the project's motto ("Of course it runs NetBSD") suggests, NetBSD has been ported to a numerous 32- and 64-bit architectures. These range from VAX minicomputers to Pocket PC PDAs. NetBSD has also been ported to several video game consoles such as the Sega Dreamcast^[20] and the Nintendo Wii.^[21] As of 2019, NetBSD supports 59 hardware platforms (across 16 different instruction sets). The kernel and userland for these platforms are all built from a central unified source-code tree managed by CVS. Unlike other kernels such as μClinux, the NetBSD kernel requires the presence of an MMU in any given target architecture.

NetBSD's portability is aided by the use of hardware abstraction layer interfaces for low-level hardware access such as bus input/output or DMA. Using this portability layer, device drivers can be split into "machine-independent" (MI) and "machine-dependent" (MD) components. This makes a single driver easily usable on several platforms by hiding hardware access details, and reduces the work to port it to a new system.^[22]

This permits a particular device driver for a PCI card to work without modifications, whether it is in a PCI slot on an IA-32, Alpha, PowerPC, SPARC, or other architecture with a PCI bus. Moreover, a single driver for a specific device can operate via several different buses, such as ISA, PCI, or PC Card.

This platform independence aids the development of embedded systems, particularly since NetBSD 1.6, when the entire toolchain of compilers, assemblers, linkers, and other tools fully support cross-compiling.

In 2005, as a demonstration of NetBSD's portability and suitability for embedded applications, Technologic Systems, a vendor of embedded systems hardware, designed and demonstrated a NetBSD-powered kitchen toaster.^[23]

Commercial ports to embedded platforms were available from and supported by Wasabi Systems, including platforms such as the AMD Geode LX800, Freescale PowerQUICC processors, Marvell Orion, AMCC 405 family of PowerPC processors, and the Intel XScale IOP and IXP series.

Portable build framework

The NetBSD cross-compiling framework (also known as "build.sh"^[24]) lets a developer build a complete NetBSD system for an architecture from a more powerful system of different architecture (cross-compiling), including on a different operating system (the framework supports most POSIX-compliant systems). Several embedded systems using NetBSD have required no additional software development other than toolchain and target rehost.^[25]

As of 2017, NetBSD had reached fully reproducible builds on amd64 and SPARC64.^[26] The build.sh -P flag handles reproducible builds automatically.

The pkgsrc packages collection

NetBSD features pkgsrc (short for "package source"), a framework for building and managing third-party application software packages. The pkgsrc collection consists of more than 29,000 packages as of September 2025^[update].^[27] Building and installing packages such as Lumina, KDE, GNOME, the Apache HTTP Server or Perl is performed through the use of a system of makefiles. This can automatically fetch the source code, unpack, patch, configure, build and install the package such that it can be removed again later. An alternative to compiling from source is to use a precompiled binary package. In either case, any prerequisites or dependencies will be installed automatically by the package system, without need for manual intervention.

pkgsrc is a cross-platform packaging system, for it supports not only NetBSD, but can be used on several other Unix-like platforms, among which macOS, Solaris and Linux are considered primary targets.^[28] Other BSDs, HP-UX, Minix, SCO UNIX (Unixware and OpenServer) and QNX have a number of active pkgsrc users but do not receive active maintenance.

pkgsrc is the default package management system on SmartOS^[29] and Minix3.^[30] It was also previously adopted as the official package management system for DragonFly BSD,^[31] and made available as an alternative packaging framework on MirBSD^[32] and QNX.^[33]

Symmetric multiprocessing

NetBSD has supported SMP since the NetBSD 2.0 release in 2004,^[34] which was initially implemented using the giant lock approach.

During the development cycle of the NetBSD 5 release, major work was done to improve SMP support; most of the kernel subsystems were modified to use the fine-grained locking approach. New synchronization primitives were implemented and scheduler activations was replaced with a 1:1 threading model in February 2007.^[35][36] A scalable M2 thread scheduler was also implemented,^[37] providing separate real-time (RT) and time-sharing (TS) queues, and improving the performance on MP systems. Threaded software interrupts were implemented to improve synchronization. The virtual memory system, memory allocator and trap handling were made MP safe. The file system framework, including the VFS and major file systems were modified to be MP safe. As of NetBSD 10.0, the only subsystems running with a giant lock are SATA device drivers, interrupt handlers, the autoconf(9) framework and most the network stack, unless the NET_MPSAFE kernel option is enabled.^[38]

In reality, starting with release 8.0, various parts of the network stack have been made MP safe already,^[39] but NET_MPSAFE is kept disabled by default, because non-MP-safe components that are also unprotected by the giant lock may otherwise crash the kernel when loaded in memory.^[40]

The 4.4BSD scheduler still remains the default, but was modified to scale with SMP, merging features from SCHED_M2.^[41] In 2017, the scheduler was changed to better distribute load of long-running processes on multiple CPUs, and tunable kern.sched sysctl(3) parameters were introduced.^[42] The release of NetBSD 10.0 brought significant performance enhancements, especially on multiprocessor and multicore systems;^[43] the scheduler gained major awareness of NUMA and hyperthreading, and became able to spread the load evenly across different physical CPUs, as well as to scale better on a mixture of slow and fast cores (e.g. ARM big.LITTLE).^[44]

Security

NetBSD supports a number of features designed to improve system security.^[45] Some are listed below.

The Kernel Authorization framework^[46] (or kauth) is a subsystem managing all authorization requests inside the kernel, and used as system-wide security policy. kauth(9) acts as a gatekeeper between kernel's own routines, by checking whether a given call or a specific operation is allowed within the context, and returns EPERM if not.^[47] Most syscalls issue an authorization request in their corresponding handler via kauth_authorize_action(). kauth also allows external modules to plug-in the authorization process.

Verified Executables (or Veriexec) is an in-kernel file integrity subsystem in NetBSD. It allows the user to set digital fingerprints (hashes) of files, and take a number of different actions if files do not match their fingerprints. For example, one can allow Perl to run only scripts that match their fingerprints.^[48]

Starting with version 2.0, NetBSD supports non-executable mappings on platforms where the hardware allows it.^[49] Process stack and heap mappings are non-executable by default. This makes exploiting potential buffer overflows harder. NetBSD supports PROT_EXEC permission via mmap() for all platforms where the hardware differentiates execute access from data access, though not necessarily with single-page granularity.^[50]

NetBSD implements several exploit mitigation features, such as ASLR (in both userland and kernel^[51][52]), restricted mprotect() (W^X) and Segvguard from the PaX project, and GCC Stack Smashing Protection (SSP, or also known as ProPolice, enabled by default since NetBSD 6.0) compiler extensions.

The cryptographic device driver (CGD) provides transparent disk encryption by acting as a logical device that is layered on top of another block device, such as a physical disk or partition (including CDs and DVDs) or a vnd(4) pseudo device.^[53] It supports the Adiantum cipher, besides AES in CBC/XTS modes.^[54]

NPF, introduced with NetBSD 6.0,^[55] is a layer 3 packet filter, supporting stateful packet inspection, IPv6, NAT, IP sets, and extensions.^[56] It uses BPF as its core engine, and supports bpfjit. NPF was designed with a focus on high performance, scalability, multi-threading and modularity.

Relevant to security are also BSD securelevels,^[57] blocklistd(8), a daemon capable of blocking ports on demand to avoid DoS abuse,^[58] and the wg(4) interface, which provides a homegrown implementation of the WireGuard protocol.^[59]

The NetBSD code is regularly scanned for bugs, and security advisories — containing a pointer to the fix — are published on the official mailing lists.^[60]

Memory management

NetBSD uses the UVM^[61] virtual memory system, developed by Charles D. Cranor at Washington University in 1998, and committed to the NetBSD source tree by Matthew Green, who handled integration issues and wrote the swap subsystem.^[62]

The original Mach based 4.4BSD system^[63] was replaced by UVM in NetBSD 1.4.^[64] UVM is designed to reduce the complexity of the 4.4BSD VM system, and offer improved performance for those applications which make heavy use of VM features, such as memory-mapped files and copy-on-write memory.^[65]

While retaining the same MD/MI layering and mapping structures of the BSD VM,^[66] UVM introduces some noticeable changes:

• Memory objects are allocated and managed in cooperation with their backing data source (typically vnodes), reducing the overhead of the vm_object chain management. The vm_page structure describes how the backing store can be accessed. Essentially, this is a pointer to a list of functions which act as bridge between UVM and the external backing store (such as a disk) that provides UVM with its data. UVM's memory object points directly to the pager operations, making the allocation of pager-related data structures more efficient.
• Anonymous pages are grouped in multi-page clusters for pageout. Each page's location on swap is assigned, so that the cluster occupies a contiguous chunk of swap and can be paged out in a single large I/O operation. This enhances paging response time for I/O operations, and allows UVM to recover quicker from page shortages.
• Memory sharing is supported using three data movement mechanisms: page loanout, page transfer, and map entry passing.^[67] A process may safely let a shared copy-on-write copy of its memory be used either by other processes, the I/O system, or the IPC system. The unified buffer cache (ubc(9)^[68] ), written by Chuck Silvers, allows to use UVM pages to cache vnode data rather than the traditional UNIX buffer cache.^[69] This avoids costly data copies, and makes more memory available for caching regular file data.

In 2003, UVM was modified to use a top-down memory management, thus merging the space reserved for heap growth and the area of space reserved for mmap(2)'ed allocations.^[70] This allows the heap to grow larger, or a process to mmap more or larger objects.

Support for RAM hot-plugging was added in 2016.^[71] The uvm_hotplug(9) API replaces the previously exposed vm_physmem static array with a red–black tree backing to keep track of memory segments, allowing the list of physical pages to be dynamically expanded or collapsed.

During the release cycle of NetBSD 10.0, major work was done to optimize the virtual memory system.^[72] The page allocator was rewritten to be more efficient and CPU topology aware, adding preliminary NUMA support. The algorithm used in the memory page lookup cache was switched to a faster radix tree. Tracking and indexing of clean/dirty pages was improved, speeding up fsync(2) on large files by orders of magnitude. Lock contention was reduced by making the maintentance of page replacement state more concurrent.

Virtualization

The Xen virtual-machine monitor has been supported in NetBSD since release 3.0. The use of Xen requires a special pre-kernel boot environment that loads a Xen-specialized kernel as the "host OS" (Dom0). Any number of "guest OSes" (DomU) virtualized computers, with or without specific Xen/DomU support, can be run in parallel with the appropriate hardware resources.

The need for a third-party boot manager, such as GRUB, was eliminated with NetBSD 5's Xen-compatible boot manager.^[73] NetBSD 6 as a Dom0 has been benchmarked comparably to Linux, with better performance than Linux in some tests.^[74]

As of NetBSD 9.0, accelerated virtualization is provided through the native type-2 hypervisor NVMM (NetBSD Virtual Machine Monitor).^[75] It provides a virtualization API, libnvmm, that can be leveraged by emulators such as QEMU.^[76][77] The kernel NVMM driver comes as a dynamically loadable kernel module, made of a generic machine-independent frontend, to which machine-dependent backends can be plugged to implement the core virtualization (currently only x86 AMD SVM and Intel VMX are supported).^[78] A unique property of NVMM is that the kernel never accesses guest VM memory, only creating it.^[79] Intel's Hardware Accelerated Execution Manager (HAXM) provides an alternative solution for acceleration in QEMU for Intel CPUs only, similar to Linux's KVM.^[80]

Rump kernels

NetBSD 5.0 introduced the rump kernel,^[81] an architecture to run drivers in user-space by emulating kernel-space calls. A rump kernel can be seen as a lightweight, portable virtualized driver execution environment, characterized by small memory footprint and minimized attack surface.^[82]

The core of a rump kernel contains a set of fundamental routines which allow it to access the host platform's resources, such as virtual memory, thread scheduler and I/O functions. This is called the rampuser(3) hypercall interface.^[83] The various kernel subsystems (e.g. TCP/IP stack, filesystems, hardware device drivers), globally referred as drivers, are layered on top of the hypercall interface, by being linked against a stripped-down version of the NetBSD kernel that can be executed in user mode. Most drivers are optional, and may be included or not depending on the target application and scope.

This "anykernel" design allows adding support of NetBSD drivers to other kernel architectures,^[84] ranging from exokernels to monolithic kernels.^[85] Other possible applications of rump kernels include deploying a task-specific unikernel to provide a POSIX API for application depending on it, running a self-contained database with minimal footprints,^[86] a userspace WireGuard instance,^[87] editing the contents of a file system as unprivileged user, and segregating a web browser to its own TCP/IP stack.^[88]

Rump kernels are also used internally by the NetBSD project for running tests on different kernel subsystems, as well as for debugging purposes.^[89]

Storage

NetBSD includes many enterprise features like iSCSI, a journaling filesystem, logical volume management and the ZFS filesystem.

The bio(4) interface for vendor-agnostic RAID volume management through bioctl has been available in NetBSD since 2007.^[90] Support for software RAID is provided as a port of CMU RAIDframe, available since NetBSD 1.4.^[91] The ccd(4) driver provides the capability of combining one or more disks/partitions into one virtual disk, acting as another in-kernel RAID 0 subsystem.^[92]

UFS2, an extension to BSD FFS adding 64-bit block pointers, variable-sized blocks (similar to extents), and extended flag fields, was ported from FreeBSD in 2003^[93] and made available since NetBSD 2.0.^[94] The fss(4)^[95] snapshot driver was introduced the same year,^[96] allowing to create a read-only, atomic view of a FFS filesystem at a given point of time; a FFS snapshot works as a special device, which can be mounted and used in conjunction with utilities like dump(8) to create and export system backups.^[97]

WAPBL, a FFS filesystem extension providing data journaling, was contributed by Wasabi Systems in 2008.^[98] Journaling allows rapid filesystem consistency after an unclean shutdown, and improves write performance by reducing synchronous metadata writes, especially when creating a large number of inodes.^[99] Support for soft updates on NetBSD FFS(v1/2) was eventually removed in favor of WAPBL.^[100]

Starting with release 10.0, FFSv2 also supports extended file attributes and ACLs^[101] as well as data TRIM.^[102]

The ZFS filesystem developed by Sun Microsystems was imported into the NetBSD base system in 2009.^[103] In 2018, the ZFS codebase was updated and rebased on FreeBSD's implementation.^[104] ZFS was finally marked safe for daily use in NetBSD 9.0.^[105] As of 10.0 release, NetBSD ZFS stack is comparable to that of FreeBSD 12 (or below), with ZFS filesystem version "5.3", zpool version "5000" (some feature flags are not supported).^[106][107] Native ZFS encryption is noticeably missing, though a zpool may be created within a cgd(4) encrypted disk.^[108] Initial support for ZFS root is available, but neither integrated in the installer nor in the bootloader.^[109]

The NetBSD Logical Volume Manager is based on a BSD reimplementation of a device-mapper driver and a port of the Linux Logical Volume Manager tools. It was mostly written during the Google Summer of Code 2008.^[110]

The CHFS Flash memory filesystem was imported into NetBSD in November 2011. CHFS is a file system developed at the Department of Software Engineering, University of Szeged, Hungary, and is the first open source Flash-specific file system written for NetBSD.

The PUFFS framework, introduced in NetBSD 5.0,^[111] is a kernel subsystem designed for running filesystems in userspace, and provides FUSE kernel level API compatibility in conjunction with the perfused(8) userland daemon.

A tmpfs implementation for NetBSD using conventional in-memory data structures, was first developed by Julio M. Merino Vidal in 2005 as a GSoC project,^[112] and merged the same year in the NetBSD source tree.^[113]

Compatibility with other operating systems

At the source code level, NetBSD is very nearly entirely compliant with POSIX.1 (IEEE 1003.1-1990) standard and mostly compliant with POSIX.2 (IEEE 1003.2-1992).

NetBSD provides system call-level binary compatibility on the appropriate processor architectures with its previous releases, but also with several other UNIX-derived and UNIX-like operating systems, including Linux, and other 4.3BSD derivatives like SunOS 4. This allows NetBSD users to run many applications that are only distributed in binary form for other operating systems, usually with no significant loss of performance.^[114] Initial support for a Haiku binary compat layer was published on the netbsd-user mailing list.^[115]

A variety of "foreign" disk filesystem formats are also supported in NetBSD, including ZFS, FAT, NTFS, Linux ext2fs, Apple HFS and Mac OS X UFS, RISC OS FileCore/ADFS, AmigaOS Fast File System, IRIX EFS, Version 7 Unix File System, and many more through PUFFS.

WINE can be installed on NetBSD through pkgsrc.^[116] Kernel support for USER_LTD — required for WoW64 — was contributed by Maxime Villard in 2017,^[117] allowing Win32 applications to be executed on amd64.^[118] The amd64 port of wine for NetBSD was completed by Naveen Narayanan as part of GSoC 2019.^[119]

Kernel scripting

Kernel-space scripting with the Lua programming language was added in NetBSD 7.0.^[120] The Lua language (i.e., its interpreter and standard libraries) was initially ported by Lourival Vieira Neto to the NetBSD kernel during GSoC 2010 and has undergone several improvements since then.^[121] The Lua (userspace) Test Suite was ported to NetBSD kernel Lua during GSoC 2015.^[122]

There are two main differences between user and kernel space Lua: kernel Lua does not support floating-point numbers; as such, only Lua integers are available.^[123] It also does not have full support to user space libraries that rely on the operating system (e.g., io and os). A sample implementation of I/O (file systems and sockets) bindings for kernel Lua was developed by Guilherme Salazar.^[124]

Possible applications of the Lua kernel interpreter include embedding extensions for the NPF packet fiter,^[125][126] and building an in-kernel application sandbox based on kauth(9), with sandbox policies provided as Lua scripts.^[127]

Kernel debugging

NetBSD provides a minimalist kernel debugger — DDB(4) — which is invoked by default whenever the kernel would otherwise panic.^[128] DDB allows to inspect processes and threads, investigate deadlocks, get a stack trace, and generate a kernel crash dump for later analysis.^[129]

Strict consistency check is enabled by building the kernel with option DIAGNOSTIC. This will cause the kernel to panic if corruption of internal data structures is detected (e.g. kernel NULL pointer dereference).^[130]

NetBSD also supports a variety of in-kernel bug detection facilities,^[131] including code sanitizers (undefined behavior, address, thread, memory sanitizers),^[132][133] a kernel memory disclosure detection system (KLEAK)^[134] and a kernel diagnostic subsystem named heartbeat(9).^[135]

LKMs

Loadable kernel modules have been supported on NetBSD since 0.9. The original lkm(4) interface ^[136] written by Terry Lambert was replaced by the new modules(7) subsystem,^[137] which supports dependency handling between modules, and loading of kernel modules on demand.^[138]

New modules can only be loaded when securelevel is less than or equal to zero, or if the kernel was built with options INSECURE, due to security concerns regarding the lack of memory protection between modules and the rest of the kernel.

Every kernel module is required to define its metadata through the C macro MODULE(class, name, required) and to implement a MODNAME_modcmd function, which the kernel calls to report important module-related events, like when the module loads or unloads.^[139]

Init

NetBSD uses a BSD style init.

Support for using an initial ramdisk is available but not enabled by default,^[140] except for specific configurations (e.g. root encryption).^[141]

The rc.d(8) framework, designed by Luke Mewburn^[142] for NetBSD 1.5,^[143] provides a fully modular service management system, using individual shell scripts for controlling services, similar to what System V does, but without runlevels.^[144] When /etc/rc/ is invoked by init(8), it executes scripts located in the /etc/rc.d directory. The order in which scripts are executed is determined by the rcorder(8) utility, based on the requirements stated in the dependency tags found within each script.^[145]

Sensors

NetBSD has featured a native hardware monitoring framework since 1999/2000. In 2003, it served as the inspiration behind the OpenBSD's sysctl hw.sensors framework when some NetBSD drivers were being ported to OpenBSD.^[146]

As of March 2019^[update], NetBSD had close to 85 device drivers exporting data through the API of the envsys framework. Since the 2007 revision, serialization of data between the kernel and userland is done through XML property lists with the help of NetBSD's proplib(3).

Sound subsystem

The NetBSD audio(4)^[147] kernel API, modelled after SunOS sound stack (SADA),^[148] provides at the same time a uniform programming interface layer above different underlying audio hardware drivers, and backend for different sound libraries (SDL, PortAudio, Mozilla cubeb) to use.

Applications may interact with the /dev/audio device node directly, using a series of ioctls specified in the sys/audioio.h header file. Audio device information may be queried with the AUDIO_GETDEV ioctl. Playing and recording sound implies opening /dev/audio for read() / write() operations and passing an audio_info struct to the kernel. This results in reduced audio latency and CPU usage compared to using additional abstraction layers (other sound libraries and/or sound servers).^[149]

The audio stack was reworked in NetBSD 8.0 to provide an in-kernel software mixing engine, with support for virtual channels;^[150] this allows more than one process to play or record audio at the same time.

A compatibility mode for the OSS API is provided by the soundcard.h header file and the libossaudio library,^[151] which internally operate using the native Sun-like audio interface.

NetBSD includes built-in MIDI support through the machine-independent midi(4)^[152] system.