Hauptentwickler Theo de Raadt hat OpenBSD in Version 7.6 angekündigt. Für die diversen Plattformen bringt die neue Version zahlreiche Verbesserungen mit.

Die FreeBSD Foundation hat bekannt gegeben, dass der deutsche Sovereign Tech Fund (STF) 686.400 Euro in das FreeBSD-Projekt investieren wird.

Die FreeBSD Community Survey wurde im Februar 2024 online durchgeführt.

Western Digital hat auf der NAB 2024 einige neue und spannende Technologien sowie Storage-Lösungen angekündigt. Ziemlich beeindruckend finde ich die Ankündigungen von microSD-Karten mit 2 TByte Speicher und SD-Karten mit 4 TByte Platz. Ein Raspberry Pi 5 mit so viel Speicherplatz ist fast schon ein vollwertiger Computer. Wobei man hier anmerken muss, dass es microSD-Karten mit 1,5 TByte bereits gibt und das ebenfalls ordentlich viel Platz ist. Genügend Platz kann man allerdings nie haben und daher ist die Ankündigung von […]

Der Beitrag SD-Karten mit 4 TByte Speicher angekündigt ist von bitblokes.de.

Die Entwickler von OpenBSD, der auf Sicherheit getrimmten BSD-Variante, haben die Version 7.5 veröffentlicht.

Das NetBSD Project hat mit NetBSD 10.0, die achtzehnte Hauptversion des NetBSD-Betriebssystems, angekündigt. Diese beinhaltet die kumulativen Verbesserungen des Betriebssystems seit NetBSD 9.3.

Der neue Raspberry Pi 5 verfügt erstmals über eine PCIe-Schnittstelle. Leider hat man sich bei der Raspberry Pi Foundation nicht dazu aufraffen können, gleich auch einen Slot für eine PCIe-SSD vorzusehen. Gut möglich, dass es auch einfach an Platzgründen gescheitert ist. Oder wird dieser Slot das Kaufargument für den Raspberry Pi 6 sein? Egal.

Mittlerweile gibt es diverse Aufsteckplatinen für den Raspberry Pi, die den Anschluss einer PCIe-SSD ermöglichen. Sie unterscheiden sich darin, ob sie über oder unter der Hauptplatine des Raspberry Pis montiert werden, ob sie kompatibel zum Lüfter sind und in welchen Größen sie SSDs aufnehmen können. (Kleinere Aufsteckplatinen sind mit den langen 2280-er SSDs überfordert.)

Update: Im Mai 2024 stellte auch die Raspberry Pi Foundation einen SSD-Adapter vor. Vorteil: billig. Nachteil: nur für kleine SSDs geeignet (2230/2242). Siehe https://www.raspberrypi.com/news/m-2-hat-on-sale-now-for-12/

NVMe Base von Pimoroni

Für diesen Artikel habe ich die NVMe Base der britischen Firma Pimoroni ausprobiert (Link). Inklusive Versand kostet das Teil ca. 24 €, der Zoll kommt gegebenenfalls hinzu. Die Platine wird mit einem winzigen Kabel und einer Menge Schrauben geliefert.

Der Zusammenbau ist fummelig, aber nicht besonders schwierig. Auf YouTube gibt es eine ausgezeichnete Anleitung. Achten Sie darauf, dass Sie wirklich eine PCIe-SSD verwenden und nicht eine alte M2-SATA-SSD, die Sie vielleicht noch im Keller liegen haben!

Nachdem Sie alles zusammengeschraubt haben, starten Sie Ihren Raspberry Pi neu (immer noch von der SD-Karte). Vergewissern Sie sich mit lsblk im Terminal, dass die SSD erkannt wurde! Entscheidend ist, dass die Ausgabe eine oder mehrere Zeilen mit dem Devicenamen nmve0n1* enthält.

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0  29,7G  0 disk 
├─mmcblk0p1 179:1    0   512M  0 part /boot/firmware
└─mmcblk0p2 179:2    0  29,2G  0 part 
nvme0n1     259:0    0 476,9G  0 disk 

Raspberry-Pi-OS klonen und von der SSD booten

Jetzt müssen Sie Ihre Raspberry-Pi-OS-Installation von der SD-Karte auf die SSD übertragen. Dazu starten Sie das Programm Zubehör/SD Card Copier, wählen als Datenquelle die SD-Karte und als Ziel die SSD aus.

SD Card Copier kopiert das Dateisystem im laufenden Betrieb, was ein wenig heikel ist und im ungünstigen Fall zu Fehlern führen kann. Der Prozess dauert ein paar Minuten. Während dieser Zeit sollten Sie auf dem Raspberry Pi nicht arbeiten! Das Kopier-Tool passt die Größe der Partitionen und Dateisysteme automatisch an die Größe der SSD an.

Als letzten Schritt müssen Sie nun noch den Boot-Modus ändern, damit Ihr Raspberry Pi in Zukunft die SSD als Bootmedium verwendet, nicht mehr die SD-Karte. Dazu führen Sie im Terminal sudo raspi-config aus und wählen Advanced Options -> Boot Order -> NVMe/USB Boot.

Selbst wenn alles klappt, verläuft der nächste Boot-Vorgang enttäuschend. Der Raspberry Pi lässt sich mit der Erkennung der SSD so viel Zeit, dass die Zeit bis zum Erscheinen des Desktops sich nicht verkürzt, sondern im Gegenteil ein paar Sekunden verlängert (bei meinen Tests ca. 26 Sekunden, mit SD-Karte nur 20 Sekunden). Falls Sie sich unsicher sind, ob die SSD überhaupt verwendet wird, führen Sie noch einmal lsblk aus. Der Mountpoint / muss jetzt bei einem nvme-Device stehen:

lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme0n1     259:0    0 476,9G  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part /boot/firmware
└─nvme0n1p2 259:2    0 476,4G  0 part /

Wie viel die SSD an Geschwindigkeit bringt, merken Sie am ehesten beim Start großer Programme (Firefox, Chromium, Gimp, Mathematica usw.), der jetzt spürbar schneller erfolgt. Auch größere Update (sudo apt full-upgrade) gehen viel schneller vonstatten.

Benchmark-Tests

Ist die höhere Geschwindigkeit nur Einbildung, oder läuft der Raspberry Pi wirklich schneller? Diese Frage beantworten I/O-Benchmarktests. (I/O steht für Input/Output und bezeichnet den Transfer von Daten zu/von einem Datenträger.)

Ich habe den Pi Benchmark verwendet. Werfen Sie immer einen Blick in heruntergeladene Scripts, bevor Sie sie mit sudo ausführen!

wget https://raw.githubusercontent.com/TheRemote/ \
       PiBenchmarks/master/Storage.sh
less Storage.sh       
sudo bash Storage.sh

Ich habe den Test viermal ausgeführt:

• Mit einer gewöhnlichen SD-Karte.
• Mit einer SATA-SSD (Samsung 840) via USB3.
• Mit einer PCIe-SSD (Hynix 512 GB PCIe Gen 3 HFS512GD9TNG-62A0A)
• Mit einer PCIe-SSD (wie oben) plus PCIe Gen 3 (Details folgen gleich).

Die Unterschiede sind wirklich dramatisch:

Modell                 Pi 5 + SD     Pi 5 + USB    Pi 5 + PCIe     Pi 5 + PCIe 3
-----------------    -----------  -------------  -------------   ---------------
Disk Read                73 MB/s       184 MB/s       348 MB/s          378 MB/s
Cached Disk Read         85 MB/s       186 MB/s       358 MB/s          556 MB/s
Disk Write               14 MB/s       121 MB/s       146 MB/s          135 MB/s
4k random read         3550 IOPS     32926 IOPS    96.150 IOPS      173.559 IOPS
4k random write         918 IOPS     27270 IOPS    81.920 IOPS       83.934 IOPS
4k read               15112 KB/s     28559 KB/s   175.220 KB/s      227.388 KB/s
4k write               4070 KB/s     28032 KB/s   140.384 KB/s      172.500 KB/s   
4k random read        13213 KB/s     17153 KB/s    50.767 KB/s       54.682 KB/s
4k random write        2862 KB/s     27507 KB/s   160.041 KB/s      203.630 KB/s        
Score                       1385           9285         34.723            43.266

Beachten Sie aber, dass das synthetische Tests sind! Im realen Betrieb fühlt sich Ihr Raspberry Pi natürlich schneller an, aber keineswegs in dem Ausmaß, den die obigen Tests vermuten lassen.

PCIe Gen 3

Standardmäßig verwendet der Raspberry Pi PCI Gen 2. Mit dem Einbau von zwei Zeilen Code in /boot/firmware/config.txt können Sie den erheblich schnelleren Modus PCI Gen 3 aktivieren. (Der Tipp stammt vom PCIe-Experten Jeff Geerling.)

# in /boot/firmware/config.txt
dtparam=pciex1
dtparam=pciex1_gen=3

Die obigen Benchmarktests beweisen, dass die Einstellung tatsächlich einiges an Zusatz-Performance bringt. Ehrlicherweise muss ich sagen, dass Sie davon im normalen Betrieb aber wenig spüren.

Bleibt noch die Frage, ob die Einstellung gefährlich ist. Die Raspberry Pi Foundation muss ja einen Grund gehabt haben, warum sie PCI Gen 3 nicht standardmäßig aktiviert hat. Zumindest bei meinen Tests sind keine Probleme aufgetreten. Auch dmesg hat keine beunruhigenden Kernel-Messages geliefert.

Fazit

Es ist natürlich cool, den Raspberry Pi mit einer schnellen SSD zu verwenden. Für Bastelprojekte ist dies nicht notwendig, aber wenn Sie vor haben, Ihren Pi als Server, NAS etc. einzusetzen, beschleunigt die SSD I/O-Vorgänge enorm.

Schön wäre, wenn der Raspberry Pi in Zukunft einen PCIe-Slot erhält, um (zumindest kurze) SSDs ohne Zusatzplatine zu nutzen. Bis dahin sind die Erweiterungsplatinen eine Übergangslösung.

In der Community ist zuletzt die Frage aufgetaucht, ob der Raspberry Pi überhaupt noch preiswert ist. Diese Frage ist nicht unberechtigt: Die Kosten für einen neuen Pi 5 + Netzteil + Lüfter + SSD-Platine + SSD + Gehäuse gehen in Richtung 150 €. Sofern Sie ein Gehäuse finden, in dem der Pi samt SSD-Platine Platz findet … Um dieses Geld bekommen Sie auch schon komplette Mini-PCs (z.B. die Chuwi Larkbox X). Je nach Anwendung muss man fairerweise zugeben, dass ein derartiger Mini-PC tatsächlich ein besserer Deal ist.

Quellen/Links

• Pimoroni NVMe Base: https://shop.pimoroni.com/products/nvme-base, https://www.youtube.com/watch?v=odG7FbptgWQ
• Pineberry (2 Modelle): https://pineberrypi.com
• Geekworm (diverse Modelle): https://geekworm.com/search?type=product&q=pcie
• PCIe Gen 3: https://www.jeffgeerling.com/blog/2023/forcing-pci-express-gen-30-speeds-on-pi-5
• Chuwi Larkbox X: https://www.derstandard.at/story/3000000204570
• When did the Raspberry Pi get so expensive? https://www.jeffgeerling.com/blog/2024/when-did-raspberry-pi-get-so-expensive
• SSD-Adapter der Raspberry Pi Foundation https://www.raspberrypi.com/news/m-2-hat-on-sale-now-for-12/

Mit der Unterstützung von Rust im Basissystem von FreeBSD könnten viele Anwendungen auf die sichere Sprache portiert werden.

Das Unternehmen CBL Datenrettung stellt in seinem Rü

Das Team von OpenBSD will den Syscall-Aufruf komplett aus seinem System entfernen. Das soll Exploits deutlich erschweren.

Das auf Sicherheit fokussierte Open-Source-Betriebssystem OpenBSD möchte den Systemaufruf Syscall komplett aus dem eigenen Kernel und der Standard-C-Bibliothek entfernen. Das kündigt der Begründer und Leiter von OpenBSD, Theo de Raadt, auf der Mailingliste des Projekts an und verschickt dazu auch passende Änderungsdateien. Ziel dieser tiefgreifenden Änderung ist, wie es bei dem Projekt zu erwarten ist, die Sicherheit zu erhöhen.

Mit Hilfe des Syscall-Aufrufs können die anderen Systemaufrufe des Betriebssystems indirekt über eine Zahl aufgerufen werden, die die entsprechende Assembler-Sprache der genutzten Plattform unterstützen muss. Dafür gibt es Tabellen, welche etwa im Fall von OpenBSD bis zur Gründung des Projekts zurückreichen. Die Idee des Syscall-Aufrufs ist dabei noch deutlich älter und stammt dabei aus dem originalen BSD von Anfang der 80er Jahre, ist seitdem aber auch von anderen unixartigen Systemen implementiert worden. In der Linux-Dokumentation etwa heißt es, der Aufruf sei sinnvoll für den Fall, falls der gewünschte Systemaufruf über keine eigene Wrapper-Funktion in der C-Bibliothek verfüge.

De Raadt begründet den Schritt mit dem Ziel, möglichst viele Aktionen unterbinden zu wollen, die bei der Ausnutzung einer Sicherheitslücke zum Ausführen von Code führen können. Er schreibt weiter: “Mir ist klar, dass wir niemals alle [von den Angreifern] verwendeten Mechanismen vollständig beseitigen können. Ich hoffe jedoch, dass ich die Programmierer von Angriffen dazu zwinge, immer kompliziertere Methoden zu verwenden. Gleichzeitig bedeutet dies, dass weniger Methoden verfügbar sind. Andere Methoden machen die Ausnutzung anfälliger. Dies drückt die Erfolgsquoten in den ‘statistischen Niedrigprozentbereich’.”

Weiter heißt es, der Entwickler versuche dabei zuerst, die einfachen Methoden zu entfernen und Angreifer eben zu immer komplexeren Aufgaben zu zwingen. In Zukunft sollen auch die komplexeren Aufgaben zum Ausnutzen von Sicherheitslücken unterbunden werden. Sollte die Änderung für den Syscall-Aufruf wie geplant umgesetzt werden, muss sich das Team zunächst aber um die damit verbundenen Auswirkungen auf andere Software kümmern. So müssen viele Programme angepasst werden, die den Aufruf bisher benutzt haben. Das gelte insbesondere für das Go-Ökosystem, schreibt de Raadt.

Der Beitrag OpenBSD will indirekte Systemaufrufe unterbinden erschien zuerst auf Linux-Magazin.

Mit OpenBSD 7.4 können die Entwickler die inzwischen 55. Release des Betriebssystems ankündigen.  Version 7.4 biete signifikante Verbesserungen, einschließlich neuer Features, in fast allen Bereichen des Systems, heißt es weiter.

Entsprechend lang ist die Liste der Neuerungen und Änderungen in der Ankündigung von Hauptentwickler Theo de Raadt.Release Notes. Zu den Neuerungen zählt ein kqueue1()-Systemaufruf, der ein Close-on-Exec-Verhalten ermöglicht. Außerdem gibt es eine verbesserte Integrität des Arm64-Kontrollflusses und Unterstützung für TCP-Segmentierungs-Offloading.

Zu en Bugfixes zählt, dass es kein undefiniertes Verhalten bei der Verwendung von MS-DOS-Dateisystemen mehr gibt. Die Korrekturen für diesen Bug habe man von FreeBSD importiert, teilt de Raadt mit.

Zudem ist es VMM-Gästen nun erlaubt, Supervisor IBT (Indirect Branch Tracking)zu aktivieren und zu verwenden. Bei den Treibern gibt es ebenfalls diverse Updates, etwa einen Treiber für den Qualcomm RNG-Chip, der auf dem ThinkPad X13s als Random Number Generator zum Einsatz kommt. In der Mitteilung sind alle Neuerungen und Änderungen vermerkt.

Der Beitrag OpenBSD 7.4 bringt Neuerungen erschien zuerst auf Linux-Magazin.

OPNsense verliert sich mehr und mehr. Kommentar eines Admins, der mehr als ein Dutzend davon betreut.

Quelle

Die Entwickler von FreeBSD haben mit Version 13.2 die dritte Ausgabe im stabilen 13er-Zweig veröffentlicht und dabei eine ganze Reihe von aktualisierten Paketen integriert.

So kommt OpenSSH in Version 9.2p1 und OpenSSL in Ausgabe 1.1.1t. ZFS wurde auf OpenZFS Version 2.1.9 aktualisiert, Sendmail auf Version 8.17.1 und Sqlite auf die Version 3.40.1.

Dass der Bhyve-Hypervisor jetzt mehr als 16 virtuelle CPUs in einem Gast unterstützt, zählt zu den neuen Features. Standardmäßig erlaubt bhyve jedem Gast, die gleiche Anzahl von vCPUs zu erzeugen wie die Anzahl der physischen CPUs auf dem Host. Diese Grenze kann über die Loader-Tunable hw.vmm.maxcpu angepasst werden.

Dass sich nun Snapshots auf UFS-Dateisystemen erstellen lassen, wenn diese mit Journalde Soft-Updates betrieben werden, ist ebenfalls neu.

FreeBSD 13.2 ist für die Architekturen amd64, i386, powerpc, powerpc64, powerpc64le, powerpcspe, armv6, armv7, aarch64 und riscv64 verfügbar.

Der Beitrag FreeBSD 13.2 bringt Updates und Features erschien zuerst auf Linux-Magazin.

Das Betriebssystem helloSystem 0.8 basiert auf FreeBSD 13.1-RELEASE und lehnt sich beim Design eindeutig an macOS an. Auf GitHub ist unter den Entwicklern auch Clement Lefebvre gelistet und den kennen die meisten Linuxer als die treibende Kraft hinter Linux Mint. Aus diesem Grund war ich auch neugierig und habe mir das System kurz angesehen. Die VirtualBox Guest Additions sind vorinstalliert und deswegen war es einfach, das Betriebssystem in VirtualBox zu betreiben. Einige AppImage-Dateien lassen sich nun über den Befehl launch […]

Der Beitrag helloSystem 0.8 – FreeBSD im macOS Look ist von bitblokes.de.

Ab sofort kannst Du eine erste Beta-Version von OpenVPN 2.6 testen. Es ist ein wichtiger Meilenstein, weil es Unterstützung für Data Channel Offloading (DCO) Kernel-Beschleunigung bietet – für Linux, FreeBSD und Windows. Wer sich wie ich für VPNs interessiert, ist über mehr Performance immer dankbar. Die Beschleunigung wird mit dem Kernel-Modul ovpn-dco umgesetzt, das sich bisher allerdings noch nicht im Mainline-Kernel befindet. Im Blog von OpenVPN findest Du weitere Informationen zu DCO und auch Benchmarks, die zeigen sollen, dass das […]

Der Beitrag OpenVPN 2.6 Beta mit DCO unterstützt OpenSSL 3.0 ist von bitblokes.de.

Die Entwickler von FreeBSD haben ein Advisory für eine über das Ping-Programm ausnutzbare Sicherheitslücke herausgegeben. Über das Ping-Kommando könnte unter Umständen Schadcode eingeschmuggelt werden, heißt es in der Warnung der Entwickler.

Anwender von FreeBSD müssen ihr System auf den neuesten Stand bringen, um das Problem zu beheben, heißt es in der Meldung. Die jeweilige Vorgehensweise dafür ist im Advisory beschrieben.

Mit Ping lässt sich die Erreichbarkeit eines entfernten Hosts mit Hilfe von ICMP-Nachrichten testen. Um ICMP-Nachrichten zu senden und zu empfangen, verwendet Ping RAW-Sockets und benötige daher erhöhte Rechte, teilen die FreeBSD-Entwickler mit.

Ping lese IP-Pakete aus dem Netz, um die Antworten mit der Funktion pr_pack() zu verarbeiten.  Als Teil der Verarbeitung muss ping den IP-Header, den ICMP-Header und, falls vorhanden, ein “zitiertes Paket” rekonstruieren, das das Paket darstellt, das einen ICMP-Fehler erzeugt hat, teilt FreeBSD mit.  Das “quoted packet” habe wiederum einen IP-Header und einen ICMP-Header.

Die Funktion pr_pack() kopiere die empfangenen IP- und ICMP-Header zur weiteren Verarbeitung in Stack Buffers.  Und dabei entstehe das Problem, weil das mögliche Vorhandensein von IP-Options-Headern nach dem IP-Header weder in der Antwort noch in dem zitierten Paket berücksichtigt werde. Sei diese IP-Optionen vorhanden, überlaufe pr_pack() den Zielpuffer um bis zu 40 Bytes, heißt es weiter.

Dieser Speichersicherheitsfehler könne von einem entfernten Host ausgelöst werden und das Ping-Programm zum Absturz bringen.  Es sei auch möglich sein, dass ein bösartiger Host die eine Remotecodeausführung in Ping auslöse.

Der Beitrag FreeBSD warnt vor Ping-Sicherheitslücke erschien zuerst auf Linux-Magazin.