NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

OpenBSD 6.7 on PC Engines APU4D4

I just got myself a PC Engines APU4D4. I miss an OpenBSD box providing home services. It’s quite simple to install and run OpenBSD on this machine. And you can even update the BIOS from OpenBSD.

---

NetBSD code study

---

News Roundup

Booting FreeBSD off the HPE MicroServer Gen8 ODD SATA port

My small homelab post generated a ton of questions and comments, most of them specific to running FreeBSD on the HP MicroServer. I’ll try and answer these over the coming week.
Josh Paxton emailed to ask how I got FreeBSD booting on it, given the unconventional booting limitations of the hardware. I thought I wrote about it a few years ago, but maybe it’s on my proverbial draft heap. If you’re impatient, the script is in my lunchbox.

---

3 ways to multiboot

multiboot installation of a BSD system with other operating systems
(OSs) on UEFI hardware is not officially supported by any of the
popular

---

Beastie Bits

• pfSense2.4.5-Release-p1 now available
• BSDCan 2020 TomSmyth - OpenBSD And OpenBGPD As ISP Controlplane
• OpenBSD DRM Update *** ###Tarsnap
• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• James - Apple T2

• Michael - Jordyns ZFS Question

  • Note from JT

• Rob - FreeBSD Freindly Registrar

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

Headlines

HyperbolaBSD Announcement

Due to the Linux kernel rapidly proceeding down an unstable path, we are planning on implementing a completely new OS derived from several BSD implementations.

This was not an easy decision to make, but we wish to use our time and resources to create a viable alternative to the current operating system trends which are actively seeking to undermine user choice and freedom.

This will not be a "distro", but a hard fork of the OpenBSD kernel and userspace including new code written under GPLv3 and LGPLv3 to replace GPL-incompatible parts and non-free ones.

• Reasons for this include:
  • Linux kernel forcing adaption of DRM, including HDCP.
  • Linux kernel proposed usage of Rust (which contains freedom flaws and a centralized code repository that is more prone to cyber attack and generally requires internet access to use.)
  • Linux kernel being written without security and in mind. (KSPP is basically a dead project and Grsec is no longer free software)
  • Many GNU userspace and core utils are all forcing adaption of features without build time options to disable them. E.g. (PulseAudio / SystemD / Rust / Java as forced dependencies)
  • As such, we will continue to support the Milky Way branch until 2022 when our legacy Linux-libre kernel reaches End of Life.

Future versions of Hyperbola will be using HyperbolaBSD which will have the new kernel, userspace and not be ABI compatible with previous versions.

HyperbolaBSD is intended to be modular and minimalist so other projects will be able to re-use the code under free license.

• Forum Post

A simple IPFW In-Kernel NAT setup on FreeBSD

After graduating college, I am moving from Brooklyn, NY to Redmond, WA (guess where I got a job). I always wanted to re-do my OPNsense firewall (currently a HP T730) with stock FreeBSD and IPFW’s in-kernel NAT.

Why IPFW? Benchmarks have shown IPFW to be faster which is especially good for my Tor relay, and because I can! However, one downside of IPFW is less documentation vs PF, even less without natd (which we’re not using), and this took me time to figure this out.

But since my T730 is already packed, I am testing this on a old PC with two NICs, and my laptop [1] as a client with an USB-to-Ethernet adapter.

News Roundup

HEADS UP: Wayland and WebRTC enabled for NetBSD 9/Linux

This is just a heads up that the Wayland option is now turned on by

default for NetBSD 9 and Linux in cases where it peacefully coexists
with X11.

• Right now, this effects the following packages:
  • graphics/MesaLib
  • devel/SDL2
  • www/webkit-gtk
  • x11/gtk3

The WebRTC option has also been enabled by default on NetBSD 9 for two Firefox versions: www/firefox, www/firefox68

Please keep me informed of any fallout. Hopefully, there will be none.

If you want to try out Wayland-related things on NetBSD 9, wm/velox/MESSAGE may be interesting for you.

LLDB Threading support now ready for mainline

Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages.

In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support, extending NetBSD's ptrace interface to cover more register types and fix compat32 issues and fixing watchpoint support. Then, I've started working on improving thread support which is taking longer than expected. You can read more about that in my September 2019 report.

So far the number of issues uncovered while enabling proper threading support has stopped me from merging the work-in-progress patches. However, I've finally reached the point where I believe that the current work can be merged and the remaining problems can be resolved afterwards. More on that and other LLVM-related events happening during the last month in this report.

OpenSSH U2F/FIDO support in base

Hardware backed keys can be generated using "ssh-keygen -t ecdsa-sk" (or "ed25519-sk" if your token supports it). Many tokens require to be touched/tapped to confirm this step.

You'll get a public/private keypair back as usual, except in this case, the private key file does not contain a highly-sensitive private key but instead holds a "key handle" that is used by the security key to derive the real private key at signing time.

So, stealing a copy of the private key file without also stealing your security key (or access to it) should not give the attacker anything.

drm/i915: Update to Linux 4.8.17

• drm/i915: Update to Linux 4.8.17
  • Broxton, Valleyview and Cherryview support improvements
  • Broadwell and Gen9/Skylake support improvements
  • Broadwell brightness fixes from OpenBSD
  • Atomic modesetting improvements
  • Various bug fixes and performance enhancements

Beastie Bits

• Visual Studio Code port for FreeBSD
• OpenBSD syscall call-from verification
• Peertube on OpenBSD
• Fuzzing Filesystems on NetBSD via AFL+KCOV by Maciej Grochowski
• Twitter Bot for Prop65
• Interactive vim tutorial
• First BSD user group meeting in Hamilton, February 11, 2020 18:30 - 21:00, Boston Pizza on Upper James St ***

Feedback/Questions

• Samir - cgit
• Russell - R
• Wolfgang - Question

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Headlines

Replacing a (silently) failing disk in a ZFS pool

Maybe I can’t read, but I have the feeling that official documentations explain every single corner case for a given tool, except the one you will actually need. My today’s struggle: replacing a disk within a FreeBSD ZFS pool.
What? there’s a shitton of docs on this topic! Are you stupid?
I don’t know, maybe. Yet none covered the process in a simple, straight and complete manner.

OPNsense 19.7 RC1 released

Hi there,
For four and a half years now, OPNsense is driving innovation through modularising and hardening the open source firewall, with simple and reliable firmware upgrades, multi-language support, HardenedBSD security, fast adoption of upstream software updates as well as clear and stable 2-Clause BSD licensing.
We thank all of you for helping test, shape and contribute to the project! We know it would not be the same without you.
Download links, an installation guide[1] and the checksums for the images can be found below as well.

News Roundup

Implementation of DRM ioctl Support for NetBSD kernel

• What is DRM ioctl ?

Ioctls are input/output control system calls and DRM stands for direct rendering manager The DRM layer provides several services to graphics drivers, many of them driven by the application interfaces it provides through libdrm, the library that wraps most of the DRM ioctls. These include vblank event handling, memory management, output management, framebuffer management, command submission & fencing, suspend/resume support, and DMA services.

• Native DRM ioctl calls

NetBSD was able to make native DRM ioctl calls with hardware rendering once xorg and proper mesa packages where installed. We used the glxinfo and glxgears applications to test this out.

High quality / low latency VOIP server with umurmur/Mumble on OpenBSD

Discord users keep telling about their so called discord server, which is not dedicated to them at all. And Discord has a very bad quality and a lot of voice distorsion.
Why not run your very own mumble server with high voice quality and low latency and privacy respect? This is very easy to setup on OpenBSD!
Mumble is an open source voip client, it has a client named Mumble (available on various operating system) and at least Android, the server part is murmur but there is a lightweight server named umurmur. People authentication is done through certificate generated locally and automatically accepted on a server, and the certificate get associated with a nickname. Nobody can pick the same nickname as another person if it’s not the same certificate.

TMWL June’19 — JS Fetch API, scheduling in Spring, thoughts on Unix

• Unix — going back to the roots

From time to time, I like to review my knowledge in a certain area, even when I feel like I know a lot about it already. I go back to the basics and read tutorials, manuals, books or watch interesting videos.
I’ve been using macOS for a couple of years now, previously being a linux user for some (relatively short) time. Both these operating systems have a common ancestor — Unix. While I’m definitely not an expert, I feel quite comfortable using linux & macOS — I understand the concepts behind the system architecture, know a lot of command line tools & navigate through the shell without a hassle. So-called unix philosophy is also close to my heart. I always feel like there’s more I could squeeze out of it.
Recently, I found that book titled “Unix for dummies, 5th edition” which was published back in… 2004. Feels literally like AGES in the computer-related world. However, it was a great shot — the book starts with the basics, providing some brief history of Unix and how it came to life. It talks a lot about the structure of the system and where certain pieces fit (eg. “standard” set of tools), and how to understand permissions and work with files & directories. There’s even a whole chapter about shell-based text editors like Vi and Emacs! Despite the fact that I am familiar with most of these, I could still find some interesting pieces & tools that I either knew existed (but never had a chance to use), or even haven’t ever heard of. And almost all of these are still valid in the modern “incarnations” of Unix’s descendants: Linux and macOS.
The book also talks about networking, surfing the web & working with email. It’s cute to see pictures of those old browsers rendering “ancient” Internet websites, but hey — this is how it looked like no more than fifteen years ago!
I can really recommend this book to anyone working on modern macOS or Linux — you will certainly find some interesting pieces. Especially if you like to go back to the roots from time to time as I do!

ThePDP-7 Where Unix Began

In preparation for a talk on Seventh Edition Unix this fall, I stumbled upon a service list from DEC for all known PDP-7 machines. From that list, and other sources, I believe that PDP-7 serial number 34 was the original Unix machine.
V0 Unix could run on only one of the PDP-7s. Of the 99 PDP-7s produced, only two had disks. Serial number 14 had an RA01 listed, presumably a disk, though of a different type. In addition to the PDP-7 being obsolete in 1970, no other PDP-7 could run Unix, limiting its appeal outside of Bell Labs. By porting Unix to the PDP-11 in 1970, the group ensured Unix would live on into the future. The PDP-9 and PDP-15 were both upgrades of the PDP-7, so to be fair, PDP-7 Unix did have a natural upgrade path (the PDP-11 out sold the 18 bit systems though ~600,000 to ~1000). Ken Thompson reports in a private email that there were 2 PDP-9s and 1 PDP-15 at Bell Labs that could run a version of the PDP-7 Unix, though those machines were viewed as born obsolete.

LLDB: watchpoints, XSTATE in ptrace() and core dumps

Upstream describes LLDB as a next generation, high-performance debugger. It is built on top of LLVM/Clang toolchain, and features great integration with it. At the moment, it primarily supports debugging C, C++ and ObjC code, and there is interest in extending it to more languages.
In February, I have started working on LLDB, as contracted by the NetBSD Foundation. So far I've been working on reenabling continuous integration, squashing bugs, improving NetBSD core file support and lately extending NetBSD's ptrace interface to cover more register types and fix compat32 issues. You can read more about that in my May 2019 report.
In June, I have finally finished the remaining ptrace() work for xstate and got it merged both on NetBSD and LLDB end (meaning it's going to make it into NetBSD 9). I have also worked on debug register support in LLDB, effectively fixing watchpoint support. Once again I had to fight some upstream regressions.

Beastie Bits

• Project Trident 19.07 Available
• A list of names from "Cold Blood" -- Any familiar?
• fern: a curses-based mastodon client modeled off usenet news readers & pine, with an emphasis on getting to 'timeline zero'
• OpenBSD Community goes Platinum for 2019!
• tcp keepalive and dports on DragonFly

Feedback/Questions

• Patrick - OpenZFS/ZoL Module from Ports
• Brad - Services not starting
• Simon - Feedback

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

Headlines

DragonflyBSD 5.6 is out

• Version 5.6.0 released 17 June 2019

• Version 5.6.1 released 19 June 2019

• Big-ticket items

• Improved VM

  • Informal test results showing the changes from 5.4 to 5.6 are available.
  • Reduce stalls in the kernel vm_page_alloc() code (vm_page_list_find()).
  • Improve page allocation algorithm to avoid re-iterating the same queues as the search is widened.
  • Add a vm_page_hash*() API that allows the kernel to do heuristical lockless lookups of VM pages.
  • Change vm_hold() and vm_unhold() semantics to not require any spin-locks.
  • Change vm_page_wakeup() to not require any spin-locks.
  • Change wiring vm_page's no longer manipulates the queue the page is on, saving a lot of overhead. Instead, the page will be removed from its queue only if the pageout demon encounters it. This allows pages to enter and leave the buffer cache quickly.
  • Refactor the handling of fictitious pages.
  • Remove m->md.pv_list entirely. VM pages in mappings no longer allocate pv_entry's, saving an enormous amount of memory when multiple processes utilize large shared memory maps (e.g. postgres database cache).
  • Refactor vm_object shadowing, disconnecting the backing linkages from the vm_object itself and instead organizing the linkages in a new structure called vm_map_backing which hangs off the vm_map_entry.
  • pmap operations now iterate vm_map_backing structures (rather than spin-locked page lists based on the vm_page and pv_entry's), and will test/match operations against the PTE found in the pmap at the requisite location. This doubles VM fault performance on shared pages and reduces the locking overhead for fault and pmap operations.
  • Simplify the collapse code, removing most of the original code and replacing it with simpler per-vm_map_entry optimizations to limit the shadow depth.

• DRM

  • Major updates to the radeon and ttm (amd support code) drivers. We have not quite gotten the AMD support up to the more modern cards or Ryzen APUs yet, however.
  • Improve UEFI framebuffer support.
  • A major deadlock has been fixed in the radeon/ttm code.
  • Refactor the startup delay designed to avoid conflicts between the i915 driver initialization and X startup.
  • Add DRM_IOCTL_GET_PCIINFO to improve mesa/libdrm support.
  • Fix excessive wired memory build-ups.
  • Fix Linux/DragonFly PAGE_MASK confusion in the DRM code.
  • Fix idr_*() API bugs.

• HAMMER2

  • The filesystem sync code has been rewritten to significantly improve performance.
  • Sequential write performance also improved.
  • Add simple dependency tracking to prevent directory/file splits during create/rename/remove operations, for better consistency after a crash.
  • Refactor the snapshot code to reduce flush latency and to ensure a consistent snapshot.
  • Attempt to pipeline the flush code against the frontend, improving flush vs frontend write concurrency.
  • Improve umount operation.
  • Fix an allocator race that could lead to corruption.
  • Numerous other bugs fixed.
  • Improve verbosity of CHECK (CRC error) console messages.

OpenBSD Vulkan Support

Somewhat surprisingly, OpenBSD has added the Vulkan library and ICD loader support as their newest port.
This new graphics/vulkan-loader port provides the generic Vulkan library and ICD support that is the common code for Vulkan implementations on the system. This doesn't enable any Vulkan hardware drivers or provide something new not available elsewhere, but is rare seeing Vulkan work among the BSDs. There is also in ports the related components like the SPIR-V headers and tools, glsllang, and the Vulkan tools and validation layers.
This is of limited usefulness, at least for the time being considering OpenBSD like the other BSDs lag behind in their DRM kernel driver support that is ported over from the mainline Linux kernel tree but generally years behind the kernel upstream. Particularly with Vulkan, newer kernel releases are needed for some Vulkan features as well as achieving decent performance. The Vulkan drivers of relevance are the open-source Intel ANV Vulkan driver and Radeon RADV drivers, both of which are in Mesa though we haven't seen any testing results to know how well they would work if at all currently on OpenBSD, but they're at least in Mesa and obviously open-source.

• A note: The BSDs are no longer that far behind.
• FreeBSD 12.0 uses DRM from Linux 4.16 (April 2018), and the drm-devel port is based on Linux 5.0 (March 2019)
• OpenBSD -current as of April 2019 uses DRM from Linux 4.19.34 ***

News Roundup

Bad utmp implementations in glibc and freebsd

I recently released another version – 0.5.0 – of Dinit, the service manager / init system. There were a number of minor improvements, including to the build system (just running “make” or “gmake” should be enough on any of the systems which have a pre-defined configuration, no need to edit mconfig by hand), but the main features of the release were S6-compatible readiness notification, and support for updating the utmp database.
In other words, utmp is a record of who is currently logged in to the system (another file, “wtmp”, records all logins and logouts, as well as, potentially, certain system events such as reboots and time updates). This is a hint at the main motivation for having utmp support in Dinit – I wanted the “who” command to correctly report current logins (and I wanted boot time to be correctly recorded in the wtmp file).
I wondered: If the files consist of fixed-sized records, and are readable by regular users, how is consistency maintained? That is – how can a process ensure that, when it updates the database, it doesn’t conflict with another process also attempting to update the database at the same time? Similarly, how can a process reading an entry from the database be sure that it receives a consistent, full record and not a record which has been partially updated? (after all, POSIX allows that a write(2) call can return without having written all the requested bytes, and I’m not aware of Linux or any of the *BSDs documenting that this cannot happen for regular files). Clearly, some kind of locking is needed; a process that wants to write to or read from the database locks it first, performs its operation, and then unlocks the database. Once again, this happens under the hood, in the implementation of the getutent/pututline functions or their equivalents.
Then I wondered: if a user process is able to lock the utmp file, and this prevents updates, what’s to stop a user process from manually acquiring and then holding such a lock for a long – even practically infinite – duration? This would prevent the database from being updated, and would perhaps even prevent logins/logouts from completing. Unfortunately, the answer is – nothing; and yes, it is possible on different systems to prevent the database from being correctly updated or even to prevent all other users – including root – from logging in to the system.

• A good find
• On FreeBSD, even though write(2) can be asynchronous, once the write syscall returns, the data is in the buffer cache (or ARC), and any future read(2) will see that new data even if it has not yet been written to disk. ***

OpenSSH gets an update to protect against Side Channel attacks

Last week, Damien Miller, a Google security researcher, and one of the popular OpenSSH and OpenBSD developers announced an update to the existing OpenSSH code that can help protect against the side-channel attacks that leak sensitive data from computer’s memory. This protection, Miller says, will protect the private keys residing in the RAM against Spectre, Meltdown, Rowhammer, and the latest RAMBleed attack.
SSH private keys can be used by malicious threat actors to connect to remote servers without the need of a password. According to CSO, “The approach used by OpenSSH could be copied by other software projects to protect their own keys and secrets in memory”.
However, if the attacker is successful in extracting the data from a computer or server’s RAM, they will only obtain an encrypted version of an SSH private key, rather than the cleartext version.
In an email to OpenBSD, Miller writes, “this change encrypts private keys when they are not in use with a symmetric key that is derived from a relatively large ‘prekey’ consisting of random data (currently 16KB).”

ZFS vs OpenZFS

You’ve probably heard us say a mix of “ZFS” and “OpenZFS” and an explanation is long-overdue.
From its inception, “ZFS” has referred to the “Zettabyte File System” developed at Sun Microsystems and published under the CDDL Open Source license in 2005 as part of the OpenSolaris operating system. ZFS was revolutionary for completely decoupling the file system from specialized storage hardware and even a specific computer platform. The portable nature and advanced features of ZFS led FreeBSD, Linux, and even Apple developers to start porting ZFS to their operating systems and by 2008, FreeBSD shipped with ZFS in the 7.0 release. For the first time, ZFS empowered users of any budget with enterprise-class scalability and data integrity and management features like checksumming, compression and snapshotting, and those features remain unrivaled at any price to this day. On any ZFS platform, administrators use the zpool and zfs utilities to configure and manage their storage devices and file systems respectively. Both commands employ a user-friendly syntax such as‘zfs create mypool/mydataset’ and I welcome you to watch the appropriately-titled webinar “Why we love ZFS & you should too” or try a completely-graphical ZFS experience with FreeNAS.
Oracle has steadily continued to develop its own proprietary branch of ZFS and Matt Ahrens points out that over 50% of the original OpenSolaris ZFS code has been replaced in OpenZFS with community contributions. This means that there are, sadly, two politically and technologically-incompatible branches of “ZFS” but fortunately, OpenZFS is orders of magnitude more popular thanks to its open nature. The two projects should be referred to as “Oracle ZFS” and “OpenZFS” to distinguish them as development efforts, but the user still types the ‘zfs’ command, which on FreeBSD relies on the ‘zfs.ko’ kernel module. My impression is that the terms of the CDDL license under which the OpenZFS branch of ZFS is published protects its users from any patent and trademark risks. Hopefully, this all helps you distinguish the OpenZFS project from the ZFS technology.

• There was further discussion of how the ZFSOnLinux repo will become the OpenZFS repo in the future once it also contains the bits to build on FreeBSD as well during the June 25th ZFS Leadership Meeting. The videos for all of the meetings are available here ***

Beastie Bits

• How to safely and portably close a file descriptor in a multithreaded process without running into problems with EINTR
• KnoxBug Meetup June 27th at 6pm
• BSD Pizza Night, June 27th at 7pm, Flying Pie Pizzeria, 3 Monroe Pkwy, Ste S, Lake Oswego, OR
• Difference between $x and ${x}
• Beware of Software Engineering Media Sites
• How Verizon and a BGP optimizer knocked large parts of the internet offline today
• DragonflyBSD - MDS mitigation added a while ago
• Reminder: Register for EuroBSDcon 2019 in Lillehammer, Norway

Feedback/Questions

• Dave - CheriBSD
• Neb - Hello from Norway
• Lars - Ansible tutorial?

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***