FreeBSD 12.0-RELEASE Announced
FreeBSD 12.0 arrived with UEFI+GELI installation, bectl boot environments, LLVM 6.0.1, VIMAGE by default, netdump, and newer bhyve.
The FreeBSD Release Engineering Team announced FreeBSD 12.0-RELEASE on December 11, 2018. It was the first release from the stable/12 branch and the result of a cycle that began freezing the development tree in August, created stable/12 on October 19, and passed through four BETA and three RC builds before the final images. Its changes touched secure installation, networking, crash diagnosis, virtualization, and the base toolchain.
Secure installation and boot environments improved
bsdinstall(8) and the ZFS boot code gained a supported UEFI plus GELI installation option. Administrators could select an encrypted root installation that booted through UEFI without assembling the layout manually. This was an installation option, not an automatic conversion: upgrading an existing machine to 12.0 did not encrypt its disks or replace its partitioning scheme.
FreeBSD 12.0 also added bectl(8) to the base system. The utility manages ZFS boot environments through an interface similar to the earlier sysutils/beadm package. A boot environment is a bootable ZFS-root clone that can preserve the pre-upgrade system state and be selected if an update fails. bectl requires an appropriate ZFS dataset layout; its presence alone does not give UFS systems snapshot-based rollback.
The release’s Lua loader work supported this broader boot story. Boot loaders, encryption, ZFS datasets, firmware mode, and boot environments must cooperate before the kernel starts, so the UEFI+GELI checkbox represented integration across more layers than the installer screen suggested.
Toolchain and base software moved together
Clang, LLVM, LLD, LLDB, compiler-rt, and libc++ were updated to 6.0.1. OpenSSL moved to 1.1.1a, the then-current LTS family; OpenSSH to 7.8p1; and Unbound to 1.8.1, with DANE-TA enabled by default. These exact versions are recorded in the contemporary announcement and matter when reconstructing an old system’s cryptographic behavior.
Userland gained practical tools and options too. dd(1) added status=progress, date(1) added ISO 8601 output through -I, and ls(1) gained a GNU-compatible --color=when option. GELI could initialize multiple providers using the same passphrase or key. Each item was small compared with a major compiler upgrade, but together they reduced the number of routine tasks that required ports or local scripts.
The random subsystem removed Yarrow, leaving Fortuna as its sole available algorithm. That was a generator implementation change, not a reason for applications to implement their own randomness or bypass documented interfaces.
Networking, isolation, and crash analysis expanded
The VIMAGE kernel option became enabled by default. VIMAGE virtualizes network-stack state and is the foundation for VNET jails, where a jail can have its own interfaces, routing tables, and firewall context instead of sharing the host’s global network stack. FreeBSD 12.0 also made PF usable inside a VNET jail. Administrators still had to configure the jail and network topology; a compiled-in option did not isolate existing jails automatically.
On amd64, the GENERIC and MINIMAL kernels enabled NUMA support by default. The new netdump(4) driver allowed a kernel crash dump to be transmitted to a remote host after panic, useful when local storage was unavailable or itself part of the failure. Compressed kernel dumps gained gzip and Zstandard-related support through the corresponding kernel options.
These facilities improved evidence collection but required pre-incident configuration. A machine cannot improvise a trusted dump server, network path, and destination after it has panicked. Operators interested in remote dumps needed to test the path while the system was healthy and protect dumps because kernel memory may contain credentials or sensitive application data.
bhyve and storage continued maturing
bhyve(8) gained NVMe device emulation, virtio_scsi(4) storage, and userland control over virtual CPU topology. A new security.jail.vmm_allowed sysctl allowed bhyve use inside a jail when explicitly enabled. That setting expanded deployment options but also widened the jail’s access to virtualization infrastructure, so it was a deliberate trust decision rather than a generic hardening recommendation.
Storage changes included UFS/FFS TRIM request consolidation, enabled by default, and new geom(8) output for provider classes and the GEOM hierarchy. The NFS 4.1 server added pNFS support. Those changes addressed very different workloads—flash-backed local filesystems, storage topology diagnosis, and distributed NFS service—but demonstrate how a major FreeBSD release aggregates work across the integrated base system.
Support status belongs in historical context
At announcement, the Project said the FreeBSD 12 series would be supported until at least June 30, 2020 while the support model was under review. That was an initial floor, not 12.0’s eventual lifecycle. The 12 series continued through FreeBSD 12.4 and is now unsupported. A historical release article should not direct a present-day operator to install 12.0 or run its original OpenSSL and OpenSSH versions.
The safe present-day use of 12.0 media is archival testing, compatibility research, or controlled migration work without exposing the system to untrusted networks. Production hosts should use a currently supported release and consult the live Security Information page for actual EOL dates. FreeBSD 12.0 remains important because it put encrypted UEFI installation, base-system boot environments, VNET networking, remote crash dumping, and a newer LLVM stack into the same release—not because its 2018 component versions are still safe today.
Related:
Sources: