Seite 3: Der Aufstieg vom ARM

Wohl "Dank" der gut zweiwöchigen Verzögerungen beim FreeBSD-13.0-RELEASE hat es die 64-Bit-ARM-Architektur (AArch64, manchmal auch arm64) in letzter Sekunde noch geschafft, neben x86-64/amd64 die einzige Plattform mit vollem Support zu werden. FreeBSD definiert den Support in vier Stufen, wobei nur Tier 1 uneingeschränkte Unterstützung sowohl von Entwicklern, dem Release Engineering, dem Security Team, dem Ports-Management Team und eine vollständige Dokumentation erhält. Nur Tier 1 ist für den produktiven Einsatz vorgesehen. In Tier 2 befinden sich in Entwicklung befindliche Architekturen (z.B. RISC-V), Nischen-Architekturen oder Plattformen, die langsam ihr End-of-Life erreichen (z.B. i386). Tier 3 ist experimentell, Tier 4 bedeutet "kein Support".

Ed Maste, Senior Director of Technology innerhalb der FreeBSD Foundation, wies in seiner Ankündigung auf die stark ansteigende Bedeutung von AArch64 hin und lobte die großzügige finanzielle und technischen Unterstützung durch ARM. Die Build-Infrastruktur wurde von Avantek durch ihre Ampere eMAG-Systeme unterstützt, die bis zu 32-Kerne @ 3.3 GHz und bis zu 512 GiB RAM bieten. Auch AWS stellt ihre Graviton-ARM64-Systeme bereit.

Freunde der kleinen ARM-SBCs dürfen sich freuen, denn Mast kündigte auch "one or more low-cost reference [ARM-]platforms" an – Images sind bereits für den Raspberry Pi und einige Pine ROCK64-Varianten vorhanden, in FreeBSD 12.2 gab es zusätzlich Images unter anderem für den Banana Pi M1 und den BeagleBone Black. Für den Raspberry Pi 4 wurde der Netzwerk-Treiber (GENET) von NetBSD portiert. Allgemein erhielt AArch64 den Linux-Compatibility-Layer (Linux-ABI), Unterstützung für den gdb(4)-Kernel-Debugger sowie viel weitere kleine Verbesserungen.

Deutliche Fortschritte gibt es für die Allwinner-SoCs bei GPIO-Interrupts, PMW-Hardware-Support, Audio auf H3/H5, Code für den Infrarot- und den Batterie-Sensor sowie USB DRD – womit USB-Geräte auf Allwinner-Boards endlich richtig nutzbar werden. Auch RockChip-SoCs (RK3328 und RK3399) unterstützen nun PWM-Hardware, externe PCIe-Adapter sowie USB3, dazu wurde das CPU-entlastende Flow-Control und Checksum-Offloading auf der Netzwerkkarte aktiviert.

Abschied von der GCC

Bereits bei FreeBSD 12 wurde die Toolchain auf LLVM/Clang umgestellt. In FreeBSD 13.0 kommen LLVM, Clang, lld, lldb-Tools, Compiler-rt, libunwind und natürlich die libc++-Bibliotheken in Version 11.0.1 zum Einsatz. Die alten GCC-Werkzeuge wurden deaktiviert, waren aber noch für einige Nischen-Architekturen notwendig. Das Problem war der Wechsel von GCC zur restriktiven GPL3, die für FreeBSD nicht akzeptabel ist. Aus diesem Grund konnte nur zähneknirschend die unter der GPL2 stehende, veraltete GCC-4.2.1-Suite eingesetzt werden. Mit FreeBSD 13 ist der Wechsel komplett, die GCC-Suite wird zum Compilieren der wichtigen FreeBSD-Architekturen selbst nicht mehr benötigt. Wer GCC und Co. dennoch benötigt, kann die Software aus den Ports installieren.

Auch andere GNU-Tools wurde nahezu komplett durch unter der BSD-Lizenz stehende Alternativen ersetzt. In der Praxis bedeutet das teilweise mehr, teilweise aber auch weniger Geschwindigkeit und eventuell leicht unterschiedliche Parameterbezeichnungen. Eines der noch unter der GPL stehenden Tools ist "diff3".

Der Kernel von FreeBSD 13 erlaubt W^X (Speicherbereiche sind entweder beschreibbar *oder* ausführbar, nicht jedoch beides) nun auch im Userland. Anders als bei OpenBSD wird diese Option jedoch wegen eventueller Probleme mit Anwendersoftware standardmäßig (noch) nicht eingeschaltet. Über die Kernel-Settings "kern.elf32.allow_wx" und "kern.elf64.allow_wx" kann W^X eingeschaltet werden, problematische Programme lassen sich per "elfctl(1)" und die Option "wxneeded" davon ausnehmen.

Ebenfalls im Kernel ist eine Implementation von KTLS gelandet, die zu GNU/Linux kompatibel sein soll. Hardware-Treiber für AESNI (amd64) und ARMv8cryto (AArch64-SoCs, die dieses Modul besitzen) sollen Verschlüsselungsroutinen beschleunigen.

Vor allem im Bereich Netzwerk und dort im Bereich Routing gab es viele Verbesserungen und teilweise komplett neue Implementationen, die den ohnehin guten Netzwerkdurchsatz von FreeBSD nochmals beschleunigen. Der Routing-Stack samt Multi-Routing-Support beispielsweise wurde komplett neu geschrieben und basiert nun auf "Nexthops". In Nexthops sind alle notwendigen Informationen enthalten, um ein Paket zu routen – in etwa vergleichbar aber umfangreicher als die vorherige "rtentry"-Datenstruktur.

Mehr pf-Leistung dank Sponsor

Ein gutes Beispiel für durch Unternehmen gesponsorte FreeBSD-Entwicklung ist die Arbeit an "pfsync" und "if_bridge": Orange (ehemals France Télécom S.A.). Das größte Telekommunikationsunternehmen in Frankreich betreibt einen Teil seiner Business Gateways mit FreeBSD. Olivier Cochard-Labbé, Gründer des FreeNSD- und des BSD-Router-Projektes, arbeitete bei Orange und erkannte dort einige Probleme bei "pfsync", dem "Packet Filter State Table Synchronisation Interface". Dabei handelt es sich um ein Pseudo-Device, über das die Statustabellen von parallelen Netzwerkverbindungen über den Paketfilter "pf" snychron gehalten werden. Der Paketfilter "pf" ist eine Abspaltung von OpenBSDs "pf" aus dem Jahre 2004 (FreeBSD 5.3). Die Weiterentwicklung von "pf" in FreeBSD hinkt seitdem der in OpenBSD deutlich hinterher.

Um das Performance-Problem für Orange zu lösen, holte Cochard-Labbé den Entwickler Kristof Provost mit ins Boot, der Maintainer von "pf" bei FreeBSD. Provost verdoppelte den Durchsatz von "pfsync" in rund sechs Monaten. Die beiden stießen dabei auf zusätzliche Probleme bei "if_bridge", das bei FreeBSD für das Bridging verantwortlich ist. Dessen massiv genutzter BRIDGE_LOCK-Mutex (Locking) konnte komplett ersetzt werden, was den Bridge-Durchsatz laut Messungen der beiden Entwickler von 3,7 auf 18,6 Millionen Pakete pro Sekunde verbesserte, also verfünffachte.

Ein neuer copy_file_range(2)-Systemaufruf erlaubt es NFS V4.2-Clients, Dateien lokal auf einem NFS V4.2-Server kopieren zu lassen, die Datei muss nicht durch das LAN zum Client und wieder zurück zum Server übertragen werden. Die NFS-V4.2-Implementation unterstützt auch Extended Attributes (RFC 8276). Uralte Treiber für Netzwerkkarten aus den Anfängen des PCs wurden aus dem FreeBSD 13.0 entfernt, darunter NE2000, 3Com Etherlink III, AMD PCnet und viele mehr.

Bhyve, der native und von Grund auf neu entwickelte Hypervisor von FreeBSD läuft mittlerweile stabil mit *BSD-, GNU/Linux-, Windows oder anderen Gästen. Ein paar alte Werkzeuge wie "bvmconsole" und "bvmdebug" wurden entfernt, dafür gibt es mit COM3 und COM4 zwei neue serielle Schnittstellen. Über VirtIO-9p lassen sich Host- und Gast-Dateisysteme teilweise zusammen benutzen – und ja, "9p" deutet darauf hin, dass der Code aus dem glorreichen Plan 9 stammt.

Eine Snapshot-Funktion für virtuelle Maschinen unter Bhyve, die auch während des Betriebs möglich ist und so eine Live-Migration ermöglichen könnte, ist nicht ganz fertig geworden. In FreeBSD 13 ist die Funktion zwar in Bhyve enthalten, jedoch wegen der noch aktiven Entwicklung standardmäßig deaktiviert. VirtIO unterstützt nun die V1.0-Spezifikation, womit FreeBSD-Gäste besser unter den anderen Hypervisoren und unter QEMU beispielsweise mit dem emulierten Intel Q35-Chipsatz läuft.

Vorsicht beim Update von ZFS

ZFS, ursprünglich von Sun Microsystems entwickelt, wurde in drei freien Projekten teilweise getrennt voneinander weitergeführt: in Illumos, in FreeBSD und in GNU/Linux (ZoL) – hinzukommt ferner die Closed-Source-Variante von Oracle. Die drei freien Projekte haben ihre Ressourcen (und Sourcen) vor einiger Zeit im OpenZFS-Projekt zusammengeführt. Diese Codebasis ersetzt in FreeBSD 13 das "ZFS on FreeBSD" vorheriger Versionen. Es gibt neben Bedenken von Anwendern vor allem Verbesserungen in der Performance und in der Handhabung: Der ARC (Cache im RAM) arbeitet effizienter und schneller, der L2ARC (ARC-Erweiterung auf SSD) ist nun zwischen Bootvorgängen persistent, die ashift-Werte (minimale Blockgröße) und ein TRIM-Befehl wurden in die ZFS-Werkzeuge integriert. Für die Kompression wird nun "zstd" verwendet, Datasets lassen sich verschlüsseln und auch verschlüsselt per "zfs send" auf andere Pools duplizieren.

Bei einem Upgrade von FreeBSD 12.x auf 13.0 sollte zunächst von einem Upgrade der ZFS-Pools ("/usr/local/sbin/zpool upgrade tank") abgesehen werden, weil FreeBSD 13 zwar 12er-Pools lesen und schreiben, FreeBSD 12 aber bei einem Rollback mit den 13er-Pools nichts anfangen kann. Der Hinweis eines Lesers, dass nach einem Upgrade von 12.2 auf 13.0 das ZFS-Root-Dateisystem nicht gefunden wird, lässt sich durch Entfernen von

opensolaris_load="YES"

aus der /boot/loader.conf beheben.