NOTES

This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

Roundup Storage and Network Diagnostics

Security Audit of the
Capsicum and bhyve
Subsystems

News Roundup

ZFS on Linux and block IO limits show some limits of being out of the kernel

NetBSD on a ROCK64 Board

Domain Naming

BSDCan 2025 CFP

The Internet Gopher from Minnesota

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

• Brendan - MinIO

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

• Join us and other BSD Fans in our BSD Now Telegram channel

Headlines

DragonflyBSD 5.4 released

DragonFly version 5.4 brings a new system compiler in GCC 8, improved NUMA support, a large of number network and virtual machine driver updates, and updates to video support. This release is 64-bit only, as with previous releases. The details of all commits between the 5.2 and 5.4 branches are available in the associated commit messages for 5.4.0rc and 5.4.0.

• Big-ticket items
• Much better support for asymmetric NUMA (Non-Uniform Memory Access) configurations. In particular, both the memory subsystem and the scheduler now understand the Threadripper 2990WX’s architecture. The scheduler will prioritize CPU nodes with direct-attached memory and the memory subsystem will normalize memory queues for CPU nodes without direct-attached memory (which improves cache locality on those CPUs).
• Incremental performance work. DragonFly as a whole is very SMP friendly. The type of performance work we are doing now mostly revolves around improving fairness for shared-vs-exclusive lock clashes, reducing cache ping-ponging due to non-contending SMP locks (i.e. massive use of shared locks on shared resources), and so forth.
• Major updates to dports brings us to within a week or two of FreeBSD’s ports as of this writing, in particular major updates to chromium, and making the whole mess work with gcc-8.
• Major rewriting of the tty clist code and the tty locking code, significantly improving concurrency across multiple ttys and ptys.
• GCC 8
• DragonFly now ships with GCC 8.0, and runs as the default compiler. It is also now used for building dports.
• GCC 4.7.4 and GCC 5.4.1 are still installed. 4.7.4 is our backup compiler, and 5.4.1 is still there to ensure a smooth transition, but should generally not be used. buildworld builds all three by default to ensure maximum compatibility.
• Many passes through world sources were made to address various warnings and errors the new GCC brought with it.
• HAMMER2
• HAMMER2 is recommended as the default root filesystem in non-clustered mode.
• Clustered support is not yet available.
• Increased bulkfree cache to reduce the number of iterations required.
• Fixed numerous bugs.
• Improved support on low-memory machines.
• Significant pre-work on the XOP API to help support future networked operations.
• Details
• Checksums MD5 (dfly-x86_64-5.4.0_REL.img) = 7277d7cffc92837c7d1c5dd11a11b98f MD5 (dfly-x86_64-5.4.0_REL.iso) = 6da7abf036fe9267479837b3c3078408 MD5 (dfly-x86_64-5.4.0_REL.img.bz2) = a77a072c864f4b72fd56b4250c983ff1 MD5 (dfly-x86_64-5.4.0_REL.iso.bz2) = 4dbfec6ccfc1d59c5049455db914d499
• Downloads Links

DragonFly BSD is 64-bit only, as announced during the 3.8 release.

• USB: dfly-x86_64-5.4.0_REL.img as bzip2 file
• ISO: dfly-x86_64-5.4.0_REL.iso as bzip2 file
• Uncompressed ISO: dfly-x86_64-5.4.0_REL.iso (For use with VPS providers as an install image.)

Down the Gopher hole with OpenBSD, Gophernicus, and TLS

In the early 2000s I thought I had seen the worst of the web - Java applets, Macromedia (>Adobe) Flash, animated GIFs, javascript snow that kept you warm in the winter by burning out your CPU, and so on. For a time we learned from these mistakes, and started putting the burden on the server-side - then with improvements in javascript engines we started abusing it again with JSON/AJAX and it all went down hill from there.

Like cloud computing, blockchains, machine learning and a tonne of other a la mode technologies around today - most users and service providers don’t need websites that consume 1GB of memory processing JS and downloading 50MB of compressed data just to read Alice’s one-page travel blog or Bob’s notes on porting NetBSD to his blood-pressure monitor.

Before the HTTP web we relied on Prestel/Minitel style systems, BBS systems, and arguably the most accessible of all - Gopher! Gopher was similar to the locally accessed AmigaGuide format, in that it allowed users to search and retrieve documents interactively, with links and cross-references. Its efficiency and distraction-free nature make it attractive to those who are tired of the invasive, clickbait, ad-filled, javascript-laden web2/3.x. But enough complaining and evangelism - here’s how to get your own Gopher Hole!

Gophernicus is a modern gopher daemon which aims to be secure (although it still uses inetd -_-); it’s even in OpenBSD ports so at least we can rely on it to be reasonably audited.

If you need a starting point with Gopher, SDF-EU’s wiki has a good article here.

• https://sdfeu.org/w/tutorials:gopher

Finally, if you don’t like gopher(1) - there’s always lynx(1) or NCSA Mosaic!

• https://cryogenix.net/NCSA_Mosaic_OpenBSD.html

I’ve added TLS support to Gophernicus so you don’t need to use stunnel anymore. The code is ugly and unpolished though so I wouldn’t recommend for production use.

• https://github.com/0x16h/gophernicus
• https://github.com/0x16h/gophernicus/blob/master/INSTALL.openbsd

News Roundup

OpenBSD in Stereo with Linux VFIO

I use a Huawei Matebook X as my primary OpenBSD laptop and one aspect of its hardware support has always been lacking: audio never played out of the right-side speaker. The speaker did actually work, but only in Windows and only after the Realtek Dolby Atmos audio driver from Huawei was installed. Under OpenBSD and Linux, and even Windows with the default Intel sound driver, audio only ever played out of the left speaker. Now, after some extensive reverse engineering and debugging with the help of VFIO on Linux, I finally have audio playing out of both speakers on OpenBSD.

• VFIO

The Linux kernel has functionality called VFIO which enables direct access to a physical device (like a PCI card) from userspace, usually passing it to an emulator like QEMU. To my surprise, these days, it seems to be primarily by gamers who boot Linux, then use QEMU to run a game in Windows and use VFIO to pass the computer’s GPU device through to Windows. By using Linux and VFIO, I was able to boot Windows 10 inside of QEMU and pass my laptop’s PCI audio device through to Windows, allowing the Realtek audio drivers to natively control the audio device. Combined with QEMU’s tracing functionality, I was able to get a log of all PCI I/O between Windows and the PCI audio device.

• Using VFIO

To use VFIO to pass-through a PCI device, it first needs to be stubbed out so the Linux kernel’s default drivers don’t attach to it. GRUB can be configured to instruct the kernel to ignore the PCI audio device (8086:9d71) and explicitly enable the Intel IOMMU driver by adding the following to /etc/default/grub and running update-grub With the audio device stubbed out, a new VFIO device can be created from it Then the VFIO device (00:1f.3) can be passed to QEMU I was using my own build of QEMU for this, due to some custom logging I needed (more on that later), but the default QEMU package should work fine. The events.txt was a file of all VFIO events I wanted logged (which was all of them). Since I was frequently killing QEMU and restarting it, Windows 10 wanted to go through its unexpected shutdown routine each time (and would sometimes just fail to boot again). To avoid this and to get a consistent set of logs each time, I used qemu-img to take a snapshot of a base image first, then boot QEMU with that snapshot. The snapshot just gets thrown away the next time qemu-img is run and Windows always starts from a consistent state. QEMU will now log each VFIO event which gets saved to a debug-output file. With a full log of all PCI I/O activity from Windows, I compared it to the output from OpenBSD and tried to find the magic register writes that enabled the second speaker. After days of combing through the logs and annotating them by looking up hex values in the documentation, diffing runtime register values, and even brute-forcing it by mechanically duplicating all PCI I/O activity in the OpenBSD driver, nothing would activate the right speaker. One strange thing that I noticed was if I booted Windows 10 in QEMU and it activated the speaker, then booted OpenBSD in QEMU without resetting the PCI device’s power in-between (as a normal system reboot would do), both speakers worked in OpenBSD and the configuration that the HDA controller presented was different, even without any changes in OpenBSD.

A Primer on Intel HDA Most modern computers with integrated sound chips use an Intel High Definition Audio (HDA) Controller device, with one or more codecs (like the Realtek ALC269) hanging off of it. These codecs do the actual audio processing and communicate with DACs and ADCs to send digital audio to the connected speakers, or read analog audio from a microphone and convert it to a digital input stream. In my Huawei Matebook X, this is done through a Realtek ALC298 codec. On OpenBSD, these HDA controllers are supported by the azalia(4) driver, with all of the per-codec details in the lengthy azalia_codec.c file. This file has grown quite large with lots of codec- and machine-specific quirks to route things properly, toggle various GPIO pins, and unmute speakers that are for some reason muted by default. The azalia driver talks to the HDA controller and sets up various buffers and then walks the list of codecs. Each codec supports a number of widget nodes which can be interconnected in various ways. Some of these nodes can be reconfigured on the fly to do things like turning a microphone port into a headphone port. The newer Huawei Matebook X Pro released a few months ago is also plagued with this speaker problem, although it has four speakers and only two work by default. A fix is being proposed for the Linux kernel which just reconfigures those widget pins in the Intel HDA driver. Unfortunately no pin reconfiguration is enough to fix my Matebook X with its two speakers. While reading more documentation on the HDA, I realized there was a lot more activity going on than I was able to see through the PCI tracing. For speed and efficiency, HDA controllers use a DMA engine to transfer audio streams as well as the commands from the OS driver to the codecs. In the output above, the CORBWP=0; size=256 and RIRBRP=0, size=256 indicate the setup of the CORB (Command Output Ring Buffer) and RIRB (Response Input Ring Buffer) each with 256 entries. The HDA driver allocates a DMA address and then writes it to the two CORBLBASE and CORBUBASE registers, and again for the RIRB. When the driver wants to send a command to a codec, such as CORB_GET_PARAMETER with a parameter of COP_VOLUME_KNOB_CAPABILITIES, it encodes the codec address, the node index, the command verb, and the parameter, and then writes that value to the CORB ring at the address it set up with the controller at initialization time (CORBLBASE/CORBUBASE) plus the offset of the ring index. Once the command is on the ring, it does a PCI write to the CORBWP register, advancing it by one. This lets the controller know a new command is queued, which it then acts on and writes the response value on the RIRB ring at the same position as the command (but at the RIRB’s DMA address). It then generates an interrupt, telling the driver to read the new RIRBWP value and process the new results. Since the actual command contents and responses are handled through DMA writes and reads, these important values weren’t showing up in the VFIO PCI trace output that I had gathered. Time to hack QEMU.

• Logging DMA Memory Values in QEMU

Since DMA activity wouldn’t show up through QEMU’s VFIO tracing and I obviously couldn’t get Windows to dump these values like I could in OpenBSD, I could make QEMU recognize the PCI write to the CORBWP register as an indication that a command has just been written to the CORB ring. My custom hack in QEMU adds some HDA awareness to remember the CORB and RIRB DMA addresses as they get programmed in the controller. Then any time a PCI write to the CORBWP register is done, QEMU fetches the new CORB command from DMA memory, decodes it into the codec address, node address, command, and parameter, and prints it out. When a PCI read of the RIRBWP register is requested, QEMU reads the response and prints the corresponding CORB command that it stored earlier. With this hack in place, I now had a full log of all CORB commands and RIRB responses sent to and read from the codec: An early version of this patch left me stumped for a few days because, even after submitting all of the same CORB commands in OpenBSD, the second speaker still didn’t work. It wasn’t until re-reading the HDA spec that I realized the Windows driver was submitting more than one command at a time, writing multiple CORB entries and writing a CORBWP value that was advanced by two. This required turning my CORB/RIRB reading into a for loop, reading each new command and response between the new CORBWP/RIRBWP value and the one previously seen. Sure enough, the magic commands to enable the second speaker were sent in these periods where it submitted more than one command at a time.

• Minimizing the Magic

The full log of VFIO PCI activity from the Windows driver was over 65,000 lines and contained 3,150 CORB commands, which is a lot to sort through. It took me a couple more days to reduce that down to a small subset that was actually required to activate the second speaker, and that could only be done through trial and error:

• Boot OpenBSD with the full list of CORB commands in the azalia driver
• Comment out a group of them
• Compile kernel and install it, halt the QEMU guest
• Suspend and wake the laptop, resetting PCI power to the audio device to reset the speaker/Dolby initialization and ensure the previous run isn’t influencing the current test (I’m guessing there is an easier to way to reset PCI power than suspending the laptop, but oh well)
• Start QEMU, boot OpenBSD with the new kernel
• Play an MP3 with mpg123 which has alternating left- and right-channel audio and listen for both channels to play

This required a dozen or so iterations because sometimes I’d comment out too many commands and the right speaker would stop working. Other times the combination of commands would hang the controller and it wouldn’t process any further commands. At one point the combination of commands actually flipped the channels around so the right channel audio was playing through the left speaker.

• The Result

After about a week of this routine, I ended up with a list of 662 CORB commands that are needed to get the second speaker working. Based on the number of repeated-but-slightly-different values written with the 0x500 and 0x400 commands, I’m guessing this is some kind of training data and that this is doing the full Dolby/Atmos system initialization, not just turning on the second speaker, but I could be completely wrong. In any case, the stereo sound from OpenBSD is wonderful now and I can finally stop downmixing everything to mono to play from the left speaker. In case you ever need to do this, sndiod can be run with -c 0:0 to reduce the channels to one. Due to the massive size of the code needed for this quirk, I’m not sure if I’ll be committing it upstream in OpenBSD or just saving it for my own tree. But at least now the hardware support chart for my Matebook is all yeses for the things I care about. I’ve also updated the Linux bug report that I opened before venturing down this path, hoping one of the maintainers of that HDA code that works at Intel or Realtek knew of a solution I could just port to OpenBSD. I’m curious to see what they’ll do with it.

Why BSD/OS is the best candidate for being the only tested legally open UNIX

• Introduction

The UNIX® system is an old operating system, possibly older than many of the readers of this post. However, despite its age, it still has not been open sourced completely. In this post, I will try to detail which parts of which UNIX systems have not yet been open sourced. I will focus on the legal situation in Germany in particular, taking it representative of European law in general – albeit that is a stretch, knowing the diversity of European jurisdictions. Please note that familiarity with basic terms of copyright law is assumed.

• Ancient UNIX

The term “Ancient UNIX” refers to the versions of UNIX up to and including Seventh Edition UNIX (1979) including the 32V port to the VAX. Ancient UNIX was created at Bell Laboratories, a subsidiary of AT&T at the time. It was later transferred of the AT&T UNIX Support Group, then AT&T Information Systems and finally the AT&T subsidiary UNIX System Laboratories, Inc. (USL). The legal situation differs between the United States of America and Germany. In a ruling as part of the UNIX System Laboratories, Inc. v. Berkeley Software Design, Inc. (USL v. BSDi) case, a U.S. court found that USL had no copyright to the Seventh Edition UNIX system and 32V – arguably, by extension, all earlier versions of Ancient UNIX as well – because USL/AT&T had failed to affix copyright notices and could not demonstrate a trade secret. Due to the obsessive tendency of U.S. courts to consider themselves bound to precedents (cf. the infamous Pierson v. Post case), it can be reasonably expected that this ruling would be honored and applied in subsequent cases. Thus under U.S. law, Ancient UNIX can be safely assumed to belong in the public domain. The situation differs in Germany. Unlike the U.S., copyright never needed registration in order to exist. Computer programs are works in the sense of the German 1965 Act on Copyright and Related Rights (Copyright Act, henceforth CopyA) as per CopyA § 2(1) no. 1. Even prior to the amendment of CopyA § 2(1) to include computer programs, computer programs have been recognized as copyrightable works by the German Supreme Court (BGHZ 112, 264 Betriebssystem, no. 19); CopyA § 137d(1) rightly clarifies that. The copyright holder at 1979 would still have been USL via Bell Labs and AT&T. Copyright of computer programs is transferred to the employer upon creation under CopyA § 69(1). Note that this does not affect expiry (Daniel Kaboth/Benjamin Spies, commentary on CopyA §§ 69a‒69g, in: Hartwig Ahlberg/Horst-Peter Götting (eds.), Urheberrecht: UrhG, KUG, VerlG, VGG, Kommentar, 4th ed., C. H. Beck, 2018, no. 16 ad CopyA § 69b; cf. Bundestag-Drucksache [BT-Drs.] 12/4022, p. 10). Expiry occurs 70 years after the death of the (co-)author that died most recently as per CopyA § 65(1) and 64; this has been the case since at least the 1960s, meaning there is no way for copyright to have expired already (old version, as per Bundesgesetzblatt Part I No. 51 of September 16, 1965, pp. 1273‒1294). In Germany, private international law applies the so-called “Territorialitätsprinzip” for intellectual property rights. This means that the effect of an intellectual property right is limited to the territory of a state (Anne Lauber-Rönsberg, KollisionsR, in: Hartwig Ahlberg/Horst-Peter Götting (eds.), ibid., pp. 2241 et seqq., no. 4). Additionally, the “Schutzlandprinzip” applies; this means that protection of intellectual property follows the lex loci protectionis, i.e. the law of the country for which protection is sought (BGH GRUR 2015, 264 HiHotel II, no. 25; BGH GRUR 2003, 328 Sender Felsberg, no. 24), albeit this is criticized in parts of doctrine (Lauber-Rönsberg, ibid., no. 10). The “Schutzlandprinzip” requires that the existence of an intellectual property right be verified as well (BGH ZUM 2016, 522 Wagenfeld-Leuchte II, no. 19). Thus, in Germany, copyright on Ancient UNIX is still alive and well. Who has it, though? A ruling by the U.S. Court of Appeals, Tenth Circuit, in the case of The SCO Group, Inc. v. Novell, Inc. (SCO v. Novell) in the U.S. made clear that Novell owns the rights to System V – thus presumably UNIX System III as well – and Ancient UNIX, though SCO acquired enough rights to develop UnixWare/OpenServer (Ruling 10-4122 [D.C. No. 2:04-CV-00139-TS], pp. 19 et seq.). Novell itself was purchased by the Attachmate Group, which was in turn acquired by the COBOL vendor Micro Focus. Therefore, the rights to SVRX and – outside the U.S. – are with Micro Focus right now. If all you care about is the U.S., you can stop reading about Ancient UNIX here. So how does the Caldera license factor into all of this? For some context, the license was issued January 23, 2002 and covers Ancient UNIX (V1 through V7 including 32V), specifically excluding System III and System V. Caldera, Inc. was founded in 1994. The Santa Cruz Operation, Inc. sold its rights to UNIX to Caldera in 2001, renamed itself to Tarantella Inc. and Caldera renamed itself The SCO Group. Nemo plus iuris ad alium transferre potest quam ipse habet; no one can transfer more rights than he has. The question now becomes whether Caldera had the rights to issue the Caldera license. I’ve noted it above but it needs restating: Foreign decisions are not necessarily accepted in Germany due to the “Territorialitätsprinzip” and “Schutzlandprinzip” – however, I will be citing a U.S. ruling for its assessment of the facts for the sake of simplicity. As per ruling 10-4122, “The district court found the parties intended for SCO to serve as Novell’s agent with respect to the old SVRX licenses and the only portion of the UNIX business transferred outright under the APA [asset purchase agreement] was the ability to exploit and further develop the newer UnixWare system. SCO was able to protect that business because it was able to copyright its own improvements to the system. The only reason to protect the earlier UNIX code would be to protect the existing SVRX licenses, and the court concluded Novell retained ultimate control over that portion of the business under the APA.” The relevant agreements consist of multiple pieces: the base Asset Purchase Agreement “APA” (Part I) the base Asset Purchase Agreement “APA” (Part II) the Operating Agremeent and Amendment 1 to the APA the Amendment 2 to the APA The APA dates September 19, 1995, from before the Caldera license. Caldera cannot possibly have acquired rights that The Santa Cruz Operation, Inc. itself never had. Furthermore, I’ve failed to find any mention of Ancient UNIX; all that is transferred is rights to SVRX. Overall, I believe that the U.S. courts’ assesment of the facts represents the situation accurately. Thus for all intents and purposes, UNIX up to and including System V remained with Novell/Attachmate/Micro Focus. Caldera therefore never had any rights to Ancient UNIX, which means it never had the rights to issue the Caldera license. The Caldera license is null and void – in the U.S. because the copyright has been lost due to formalities, everywhere else because Caldera never had the rights to issue it. The first step to truly freeing UNIX would this be to get Micro Focus to re-issue the Caldera license for Ancient UNIX, ideally it would now also include System III and System V.

• BSD/OS

Another operating system near UNIX is of interest. The USL v. BSDi lawsuit includes two parties: USL, which we have seen above, and Berkeley Software Design, Inc. BSDi sold BSD/386 (later BSD/OS), which was a derivative of 4.4BSD. The software parts of the BSDi company were acquired by Wind River Systems, whereas the hardware parts went to iXsystems. Copyright is not disputed there, though Wind River Systems ceased selling BSD/OS products 15 years ago, in 2003. In addition, Wind River System let their trademark on BSD expire, though this is without consequence for copyright. BSD/OS is notable in the sense that it powered much of early internet infrastructure. Traces of its legacy can still be found on Richard Stevens’ FAQ. To truly make UNIX history free, BSD/OS would arguably also need to see a source code release. BSD/OS at least in its earliest releases under BSDi would ship with source code, though under a non-free license, far from BSD or even GPL licensing.

• System V

The fate of System V as a whole is difficult to determine. Various licenses have been granted to a number of vendors (Dell UNIX comes to mind; HP for HP-UX, IBM for AIX, SGI UNIX, etc.). Sun released OpenSolaris – notoriously, Oracle closed the source to Solaris again after its release –, which is a System V Release 4 descendant. However, this means nothing for the copyright or licensing status of System V itself. Presumably, the rights with System V still remain with Novell (now Micro Focus): SCO managed to sublicense rights to develop and sell UnixWare/OpenServer, themselves System V/III descendants, to unXis, Inc. (now known as Xinuos, Inc.), which implies that Xinuos is not the copyright holder of System V. Obviously, to free UNIX, System V and its entire family of descendants would also need to be open sourced. However, I expect tremendous resistance on part of all the companies mentioned. As noted in the “Ancient UNIX” section, Micro Focus alone would probably be sufficient to release System V, though this would mean nothing for the other commercial System V derivatives.

• Newer Research UNIX

The fate of Bell Labs would be a different one; it would go on to be purchased by Lucent, now part of Nokia. After commercial UNIX got separated out to USL, Research UNIX would continue to exist inside of Bell Labs. Research UNIX V8, V9 and V10 were not quite released by Alcatel-Lucent USA Inc. and Nokia in 2017. However, this is merely a notice that the companies involved will not assert their copyrights only with respect to any non-commercial usage of the code. It is still not possible, over 30 years later, to freely use the V8 code.

• Conclusion In the U.S., Ancient UNIX is freely available. People located everywhere else, however, are unable to legally obtain UNIX code for any of the systems mentioned above. The exception being BSD/OS, assuming a purchase of a legitimate copy of the source code CD. This is deeply unsatisfying and I implore all involved companies to consider open sourcing (preferably under a BSD-style license) their code older than a decade, if nothing else, then at least for the sake of historical purposes. I would like to encourage everybody reading this to consider reaching out to Micro Focus and Wind River Systems about System V and BSD/OS, respectively. Perhaps the masses can change their minds.

A small note about patents: Some technologies used in newer iterations of the UNIX system (in particular the System V derivatives) may be encumbered with software patents. An open source license will not help against patent infringement claims. However, the patents on anything used in the historical operating systems will certainly have expired by now. In addition, European readers can ignore this entirely – software patents just aren’t a thing.

OpenBGPD - Adding Diversity to the Route Server Landscape

• Introduction

As of last year, there was effectively only a single solution in the Route Server vendor market: the BIRD Internet routing daemon. NIC.CZ (the organisation developing BIRD) has done fantastic work on maintaining their BGP-4 implementation, however, it’s not healthy to have virtually every Internet Exchange Point (IXP) in the RIPE NCC service region depend on a single open source project. The current situation can be compared to the state of the DNS root nameservers back in 2002 - their dependence on the BIND nameserver daemon and the resulting development of NSD as an alternative by NLnet, in cooperation with the RIPE NCC. OpenBGPD used to be one of the most popular Route Server implementations until the early 2010s. OpenBGPD’s main problem was that its performance couldn’t keep up with the Internet’s growth, so it lost market share. An analysis by Job Snijders suggested that a modernised OpenBGPD distribution would be a most viable option to regain diversity on the Route Server level.

• Missing features in OpenBGPD

The following main missing features were identified in OpenBGPD:

• Performance

In previous versions of OpenBGPD, the filtering performance didn’t allow proper filtering of all EBGP sessions. Current best practice at IXP Route Servers is to carefully evaluate and validate of all routes learned from EBGP peers. The OpenBGPD ruleset required to do correct filtering (in many deployment scenarios) was simply too lengthy - and negatively impacted service performance during configuration reloads. While filtering performance is the biggest bottleneck, general improvements to the Routing Information Base were also made to improve scalability. IXP Route Servers with a few hundred peering sessions are commonplace and adding new sessions shouldn’t impact the Route Servers’ service to other peers. We found that performance was the most pressing issue that needed to be tackled.

• Lack of RPKI Origin Validation

As we’ve seen, Internet operators are moving to adopt RPKI based BGP Origin Validation. While it was theoretically possible to emulate RFC 6811-style Origin Validation in previous versions of OpenBGPD, the required configuration wasn’t optimised for performance and wasn’t user friendly. We believe that BGP Origin Validation should be as easy as possible - this requires BGP-4 vendors to implement native, optimised routines for Origin Validation. Of course, enabling Origin Validation shouldn’t have an impact on performance either when processing BGP updates or when updating the Route Origin Authorisation (ROA) table itself.

• Portability

OpenBGPD is an integral part of OpenBSD, but IXPs may prefer to run their services infrastructure on an operating system of their choice. Making sure that there’s a portable OpenBGPD version which follows the OpenBSD project release cycle will give IXPs this option.

• Development steps

By addressing the issues mentioned above, we could bring back OpenBGPD as a viable Route Server implementation. Since I was one of the core OpenBGPD developers, I was asked if I wanted to pick up this project again. Thanks to the funding from the RIPE NCC Project Fund, this was possible. Starting in June 2018, I worked full time on this important community project. Over the last few months, many of the problems are already addressed and are now part of the OpenBSD 6.4 release. So far, 154 commits were made to OpenBGPD during the 6.4 development cycle - around 8% of all commits ever to OpenBGPD! This shows that due to funding and dedicated resources, a lot of work could be pushed into the latest release of OpenBGPD.

• OpenBGPD 6.4

The OpenBGPD version, as part of OpenBSD 6.4 release, demonstrates great progress. Even though there have been many changes to the core of OpenBGPD, the released version is as solid and reliable as previous releases and the many bug fixes and improvements make this the best OpenBGPD release so far. The changes in the filter language allow users to write more efficient rulesets while the introduction of RPKI origination validation fixes an important missing feature. For IXPs, OpenBGPD now is an alternative again. There are still open issues, but the gap is closing!

• Feature highlights

The following changes should be highlighted:

• Introduction of background soft-reconfiguration on config reload. Running the soft-reconfiguration task in the background allows for new updates and withdraws to be processed at the same time. This improves convergence time - one of the key metrics for Route Servers.
• BGP Origin Validation when a roa-set is configured Every EBGP route announcement is validated against the locally configured VRP table entries. Depending on the validation process’s outcome, the validation state is set to valid, invalid or not found. The filter language has been extended to allow checking for the origin validation state, and thanks to this, it is possible to deny invalid prefixes or regard valid prefixes different to the ones that aren’t found. The roa-set table is read from the configuration file and updated during configuration reloads. On production systems reloading the roa-set and applying it to all prefixes is done in a couple of seconds.
• Fast prefix-set lookups In OpenBSD 6.3 prefix-sets got introduced in OpenBGPD. A prefix-set combines many prefix lookups into a single filter rule. The original implementation wasn’t optimised but now a fast trie lookup is used. Thanks to this, large IRR DB prefix tables can now be implemented efficiently.
• Introduction of as-sets Similar to prefix-sets, as-sets help group many AS numbers into a single lookup. Thanks to this, large IRR DB origin AS tables can be implemented efficiently. Introduction of origin-sets
• Looking at the configurations of Route Servers doing full filtering, it was noticed that a common lookup was binding a prefix to an origin AS - similar to how a roa-set is used for RPKI. These origin-set tables are used to extend the IRR prefix lookup and generated from alternative sources.
• Improving third party tools

Users can only benefit from the changes introduced in OpenBGPD 6.4 when the surrounding 3rd party tools are adjusted accordingly. Two opensource projects such as bgpq3 and arouteserver are frequently used by network operators and IXPs to generate BGP configurations. Thanks to our contributions to those projects, we were able to get them ready for all the new features in OpenBGPD.

• bgpq3 was extended to create as-set and prefix-set tables based on IRR DB entries. This is replacing the old way of doing the same with a large amount of filter rules. Thanks to the quick response from the bgpq3 maintainer, it was possible to ship OpenBSD 6.4 with a bgpq3 package that includes all the new features.
• arouteserver was adjusted to implement RPKI roa-set, as-set, prefix-set, and origin-set to generate a much better-performing configurations for the 6.4 version. With the v0.20.0 release of arouteserver, IXPs are able to generate an OpenBGPD configuration which is a ton faster but also implements the new functionalities. Looking at YYCIX (the resident IXP in Calgary, Canada) the ruleset generated by arouteserver was reduced from 370,000 rules to well under 6,000 rules. This resulted in the initial convergence time dropping from over 1 hour to less than 2 minutes, and subsequent configuration reloads are hitless and no longer noticeable.
• What still needs to be done

A sizeable chunk of work still left on the table is the rework of the RIB data structures in OpenBGPD - these haven’t been changed since the initial design of OpenBGPD in 2003. There’s currently ongoing work (in small steps, to avoid jeopardising the stability of OpenBGPD) to modernise these data-structures. The goal is to provide better decoupling of the filter step from storing RIB database changes, to pave the way to multi-threaded operations at a later point.

• Looking forward
• Job Snijders oversaw this year’s fundraising and project management, he adds:

It’s been incredibly productive to create an environment where a core developer is allowed to work full time on the OpenBGPD code base. However, it’s important to note there still is room for a number of new features to help improve its operational capabilities (such as BMP, RFC 7313, ADD_PATH, etc). It’d be beneficial to the Internet community at large if we can extend Claudio Jeker’s involvement for another year. Open source software doesn’t grow on trees! Strategic investments are the only way to keep OpenBGPD’s roadmap aligned with Internet growth and operator requirements.

Beastie Bits

• DragonFly - git: annotated tag v5.5.0 created
• Torchlight 2 on NetBSD
• Older, but still good USENIX Login Article on Capsicum
• The Super Capsicumizer 9000
• Dedicated and Virtual Server PXE provisioning tool
• Cirrus CI have announced FreeBSD support
• NetBSD PineBook Gameplay
• BSDCan 2019 CfP is out
• Allan’s first ZFS array, Zulu, turned 7 years old on Nov 29th

Feedback/Questions

• Malcom - Installing Drivers in Development
• Samir - Introduction to ZFS
• Newnix - Drive Failures

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

This episode was brought to you by

Headlines

OpenBSD presents tame

• Theo de Raadt sent out an email detailing OpenBSD's new "tame" subsystem, written by Nicholas Marriott and himself, for restricting what processes can and can't do
• When using tame, programs will switch to a "restricted-service operating mode," limiting them to only the things they actually need to do
• As for the background: "Generally there are two models of operation. The first model requires a major rewrite of application software for effective use (ie. capsicum). The other model in common use lacks granularity, and allows or denies an operation throughout the entire lifetime of a process. As a result, they lack differentiation between program 'initialization' versus 'main servicing loop.' systrace had the same problem. My observation is that programs need a large variety of calls during initialization, but few in their main loops."
• Some initial categories of operation include: computation, memory management, read-write operations on file descriptors, opening of files and, of course, networking
• Restrictions can also be stacked further into the lifespan of the process, but removed abilities can never be regained (obviously)
• Anything that tries to access resources outside of its in-place limits gets terminated with a SIGKILL or, optionally, a SIGABRT (which can produce useful core dumps for investigation)
• Also included are 29 examples of userland programs that get additional protection with very minimal changes to the source - only 2 or 3 lines needing changed in the case of binaries like cat, ps, dmesg, etc.
• This is an initial work-in-progress version of tame, so there may be more improvements or further control options added before it hits a release (very specific access policies can sometimes backfire, however)
• The man page, also included in the mail, provides some specifics about how to integrate tame properly into your code (which, by design, was made very easy to do - making it simple means third party programs are more likely to actually use it)
• Kernel bits are in the tree now, with userland changes starting to trickle in too
• Combined with a myriad of memory protections, tight privilege separation and (above all else) good coding practices, tame should further harden the OpenBSD security fortress
• Further discussion can be found in the usual places you'd expect ***

Using Docker on FreeBSD

• With the experimental Docker port landing in FreeBSD a few weeks ago, some initial docs are starting to show up
• This docker is "the real thing," and isn’t using a virtual machine as the backend - as such, it has some limitations
• The FreeBSD wiki has a page detailing how it works in general, as well as more info about those limitations
• When running Linux containers, it will only work as well as the Linux ABI compat layer for your version of FreeBSD (11.0, or -CURRENT when we're recording this, is where all the action is for 64bit support)
• For users on 10.X, there's also a FreeBSD container available, which allows you to use Docker as a fancy jail manager (it uses the jail subsystem internally)
• Give it a try, let us know how you find it to be compared to other solutions ***

OpenBSD imports doas, removes sudo

• OpenBSD has included the ubiquitous "sudo" utility for many years now, and the current maintainer of sudo (Todd C. Miller) is also a long-time OpenBSD dev
• The version included in the base system was much smaller than the latest current version used elsewhere, but was based on older code
• Some internal discussion lead to the decision that sudo should probably be moved to ports now, where it can be updated easily and offer all the extra features that were missing in base (LDAP and whatnot)
• Ted Unangst conjured up with a rewritten utility to replace it in the base system, dubbed "do as," with the aim of being more simple and compact
• There were concerns that sudo was too big and too complicated, and a quick 'n' dirty check reveals that doas is around 350 lines of code, while sudo is around 10,000 - which would you rather have as a setuid root binary?
• After the initial import, a number of developers began reviewing and improving various bits here and there
• You can check out the code now if you're interested
• Command usage and config syntax seem pretty straightforward
• More discussion on HN ***

What would you like to see in FreeBSD

• Adrian Chadd started a reddit thread about areas in which FreeBSD could be improved, asking the community what they'd like to see
• There are over 200 comments that span a wide range of topics, so we'll just cover a few of the more popular requests - check the very long thread if you're interested in more
• The top comment says things don't "just work," citing failover link aggregation of LACP laggs, PPPoE issues, disorganized jail configuration options, unclear CARP configuration and userland dtrace being unstable
• Another common one was that there are three firewalls in the base system, with ipfilter and pf being kinda dead now - should they be removed, and more focus put into ipfw?
• Video drivers also came up frequently, with users hoping for better OpenGL support and support for newer graphics cards from Intel and AMD - similar comments were made about wireless chipsets as well
• Some other replies included more clarity with pkgng output, paying more attention to security issues, updating PF to match the one in OpenBSD, improved laptop support, a graphical installer, LibreSSL in base, more focus on embedded MIPS devices, binary packages with different config options, steam support and lots more
• At least one user suggested better "marketing" for FreeBSD, with more advocacy and (hopefully) more business adoption
• That one really applies to all the BSDs, and regular users (that's you listening to this) can help make it happen for whichever ones you use right now
• Maybe Adrian can singlehandedly do all the work and make all the users happy ***

Interview - Ryan Lortie & Baptiste Daroussin

Porting the latest GNOME code to FreeBSD

News Roundup

Introducing resflash

• If you haven't heard of resflash before, it's "a tool for building OpenBSD images for embedded and cloud environments in a programmatic, reproducible way"
• One of the major benefits to images like this is the read-only filesystem, so there's no possibility of filesystem corruption if power is lost
• There's an optional read-write partition as well, used for any persistent changes you want to make
• You can check out the source code on Github or read the main site for more info ***

Jails with iocage

• There are a growing number of FreeBSD jail management utilities: ezjail, cbsd, warden and a few others
• After looking at all the different choices, the author of this blog post eventually settled on iocage for the job
• The post walks you through the basic configuration and usage of iocage for creating managing jails
• If you've been unhappy with ezjail or some of the others, iocage might be worth giving a try instead (it also has really good ZFS integration) ***

DragonFly GPU improvements

• DragonFlyBSD continues to up their graphics game, this time with Intel's ValleyView series of CPUs
• These GPUs are primarily used in the newer Atom CPUs and offer much better performance than the older ones
• A git branch was created to hold the fixes for now while the last remaining bugs get fixed
• Fully-accelerated Broadwell support and an update to newer DRM code are also available in the git branch, and will be merged to the main tree after some testing ***

Branchless development

• Ted Unangst has a new blog post up, talking about software branches and the effects of having (or not having) them
• He covers integrating and merging code, and the versioning problems that can happen with multiple people contributing at once
• "For an open source project, branching is counter intuitively antisocial. For instance, I usually tell people I’m running OpenBSD, but that’s kind of a lie. I’m actually running teduBSD, which is like OpenBSD but has some changes to make it even better. Of course, you can’t have teduBSD because I’m selfish. I’m also lazy, and only inclined to make my changes work for me, not everyone else."
• The solution, according to him, is bringing all the code the developers are using closer together
• One big benefit is that WIP code gets tested much faster (and bugs get fixed early on) ***

Feedback/Questions

• Matthew writes in
• Chris writes in
• Anonymous writes in
• Bill writes in ***

This episode was brought to you by

Interview - Sepherosa Ziehau - sephe@dragonflybsd.org

Features of DragonFlyBSD's network stack

Discussion

Comparing containment methods and privilege separation

• chroot, jails, systrace, capsicum, filesystem permissions, separating users ***

Feedback/Questions

• Brad writes in
• Anonymous writes in
• Benjamin writes in
• Jeroen writes in ***

This episode was brought to you by

Headlines

Playing with sandboxing

• Sandboxing and privilege separation are popular topics these days - they're the goal of the new "shill" scripting language, they're used heavily throughout OpenBSD, and they're gaining traction with the capsicum framework
• This blog post explores capsicum in FreeBSD, some of its history and where it's used in the base system
• They also include some code samples so you can verify that capsicum is actually denying the program access to certain system calls
• Check our interview about capsicum from a while back if you haven't seen it already ***

OpenNTPD on by default

• OpenBSD has enabled ntpd by default in the installer, rather than prompting the user if they want to turn it on
• In nearly every case, you're going to want to have your clock synced via NTP
• With the HTTPS constraints feature also enabled by default, this should keep the time checked and accurate, even against spoofing attacks
• Lots of problems can be traced back to the time on one system or another being wrong, so this will also eliminate some of those cases
• For those who might be curious, they're using the "pool.ntp.org" cluster of addresses and google for HTTPS constraints (but these can be easily changed) ***

FreeBSD workshop in Landshut

• We mentioned a BSD installfest happening in Germany a few weeks back, and the organizer wrote in with a review of the event
• The installfest instead became a "FreeBSD workshop" session, introducing curious new users to some of the flagship features of the OS
• They covered when to use UFS or ZFS, firewall options, the release/stable/current branches and finally how to automate installations with Ansible
• If you're in south Germany and want to give similar introduction talks or Q&A sessions about the other BSDs, get in touch
• We'll hear more from him about how it went in the feedback section today ***

Swap encryption in DragonFly

• Doing full disk encryption is very important, but something that people sometimes overlook is encrypting their swap
• This can actually be more important than the contents of your disks, especially if an unencrypted password or key hits your swap (as it can be recovered quite easily)
• DragonFlyBSD has added a new experimental option to automatically encrypt your swap partition in fstab
• There was another way to do it previously, but this is a lot easier
• You can achieve similar results in FreeBSD by adding ".eli" to the end of the swap device in fstab, there are a few steps to do it in NetBSD and swap in OpenBSD is encrypted by default
• A one-time key will be created and then destroyed in each case, making recovery of the plaintext nearly impossible ***

Interview - Jed Reynolds - jed@bitratchet.com / @jed_reynolds

Comparing ZFS on Linux and FreeBSD

News Roundup

USB thermometer on OpenBSD

• So maybe you've got BSD on your server or router, maybe NetBSD on a toaster, but have you ever used a thermometer with one?
• This blog post introduces the RDing TEMPer Gold USB thermometer, a small device that can tell the room temperature, and how to get it working on OpenBSD
• Wouldn't you know it, OpenBSD has a native "ugold" driver to support it with the sensors framework
• How useful such a device would be is another story though ***

NAS4Free now on ARM

• We talk a lot about hardware for network-attached storage devices on the show, but ARM doesn't come up a lot
• That might be changing soon, as NAS4Free has just released some ARM builds
• These new (somewhat experimental) images are based on FreeBSD 11-CURRENT
• Included in the announcement is a list of fully-supported and partially-supported hardware that they've tested it with
• If anyone has experience with running a NAS on slightly exotic hardware, write in to us ***

pkgsrcCon 2015 CFP and info

• This year's pkgsrcCon will be in Berlin, Germany on July 4th and 5th
• They're looking for talk proposals and ideas for things you'd like to see
• If you or your company uses pkgsrc, or if you're just interested in NetBSD in general, it would be a good event to check out ***

BSDTalk episode 253

• BSDTalk has released another new episode
• In it, he interviews George Neville-Neil about the 2nd edition of "The Design and Implementation of the FreeBSD Operating System"
• They discuss what's new since the last edition, who the book's target audience is and a lot more
• We're up to 90 episodes now, slowly catching up to Will... ***

Feedback/Questions

• Dominik writes in
• Brad writes in
• Corvin writes in
• James writes in ***

This episode was brought to you by

Headlines

FreeBSD quarterly status report

• The FreeBSD team has posted a report of the activities that went on between January and March of this year
• As usual, it's broken down into separate reports from the various teams in the project (ports, kernel, virtualization, etc)
• The ports team continuing battling the flood of PRs, closing quite a lot of them and boasting nearly 7,000 commits this quarter
• The core team and cluster admins dealt with the accidental deletion of the Bugzilla database, and are making plans for an improved backup strategy within the project going forward
• FreeBSD's future release support model was also finalized and published in February, which should be a big improvement for both users and the release team
• Some topics are still being discussed internally, mainly MFCing ZFS ARC responsiveness patches to the 10 branch and deciding whether to maintain or abandon C89 support in the kernel code
• Lots of activity is happening in bhyve, some of which we've covered recently, and a number of improvements were made this quarter
• Clang, LLVM and LLDB have been updated to the 3.6.0 branch in -CURRENT
• Work to get FreeBSD booting natively on the POWER8 CPU architecture is also still in progress, but it does boot in KVM for the time being
• The project to replace forth in the bootloader with lua is in its final stages, and can be used on x86 already
• ASLR work is still being done by the HardenedBSD guys, and their next aim is position-independent executable
• The report also touches on multipath TCP support, the new automounter, opaque ifnet, pkgng updates, secureboot (which should be in 10.2-RELEASE), GNOME and KDE on FreeBSD, PCIe hotplugging, nested kernel support and more
• Also of note: work is going on to make ARM a Tier 1 platform in the upcoming 11.0-RELEASE (and support for more ARM boards is still being added, including ARM64) ***

OpenBSD 5.7 released

• OpenBSD has formally released another new version, complete with the giant changelog we've come to expect
• In the hardware department, 5.7 features many driver improvements and fixes, as well as support for some new things: USB 3.0 controllers, newer Intel and Atheros wireless cards and some additional 10gbit NICs
• If you're using one of the Soekris boards, there's even a new driver to manipulate the GPIO and LEDs on them - this has some fun possibilities
• Some new security improvements include: SipHash being sprinkled in some areas to protect hashing functions, big W^X improvements in the kernel space, static PIE on all architectures, deterministic "random" functions being replaced with strong randomness, and support for remote logging over TLS
• The entire source tree has also been audited to use reallocarray, which unintentionally saved OpenBSD's libc from being vulnerable to earlier attacks affecting other BSDs' implementations
• Being that it's OpenBSD, a number of things have also been removed from the base system: procfs, sendmail, SSLv3 support and loadable kernel modules are all gone now (not to mention the continuing massacre of dead code in LibreSSL)
• Some people seem to be surprised about the removal of loadable modules, but almost nothing utilized them in OpenBSD, so it was really just removing old code that no one used anymore - very different from FreeBSD or Linux in this regard, where kernel modules are used pretty heavily
• BIND and nginx have been taken out, so you'll need to either use the versions in ports or switch to Unbound and the in-base HTTP daemon
• Speaking of httpd, it's gotten a number of new features, and has had time to grow and mature since its initial debut - if you've been considering trying it out, now would be a great time to do so
• This release also includes the latest OpenSSH (with stronger fingerprint types and host key rotation), OpenNTPD (with the HTTPS constraints feature), OpenSMTPD, LibreSSL and mandoc
• Check the errata page for any post-release fixes, and the upgrade guide for specific instructions on updating from 5.6
• Groundwork has also been laid for some major SMP scalability improvements - look forward to those in future releases
• There's a song and artwork to go along with the release as always, and CDs should be arriving within a few days - we'll show some pictures next week
• Consider picking one up to support the project (and it's the only way to get puffy stickers)
• For those of you paying close attention, the banner image for this release just might remind you of a certain special episode of BSD Now... ***

Tor-BSD diversity project

• We've talked about Tor on the show a few times, and specifically about getting more of the network on BSD (Linux has an overwhelming majority right now)
• A new initiative has started to do just that, called the Tor-BSD diversity project
• "Monocultures in nature are dangerous, as vulnerabilities are held in common across a broad spectrum. Diversity means single vulnerabilities are less likely to harm the entire ecosystem. [...] A single kernel vulnerability in GNU/Linux that impacting Tor relays could be devastating. We want to see a stronger Tor network, and we believe one critical ingredient for that is operating system diversity."
• In addition to encouraging people to put up more relays, they're also continuing work on porting the Tor Browser Bundle to BSD, so more desktop users can have easy access to online privacy
• There's an additional progress report for that part specifically, and it looks like most of the work is done now
• Engaging the broader BSD community about Tor and fixing up the official documentation are also both on their todo list
• If you've been considering running a node to help out, there's always our handy tutorial on getting set up ***

PC-BSD 10.1.2-RC1 released

• If you want a sneak peek at the upcoming PC-BSD 10.1.2, the first release candidate is now available to grab
• This quarterly update includes a number of new features, improvements and even some additional utilities
• PersonaCrypt is one of them - it's a new tool for easily migrating encrypted home directories between systems
• A new "stealth mode" option allows for a one-time login, using a blank home directory that gets wiped after use
• Similarly, a new "Tor mode" allows for easy tunneling of all your traffic through the Tor network
• IPFW is now the default firewall, offering improved VIMAGE capabilities
• The life preserver backup tool now allows for bare-metal restores via the install CD
• ISC's NTP daemon has been replaced with OpenNTPD, and OpenSSL has been replaced with LibreSSL
• It also includes the latest Lumina desktop, and there's another post dedicated to that
• Binary packages have also been updated to fresh versions from the ports tree
• More details, including upgrade instructions, can be found in the linked blog post ***

Interview - Ed Schouten - ed@freebsd.org / @edschouten

CloudABI

News Roundup

Open Household Router Contraption

• This article introduces OpenHRC, the "Open Household Router Contraption"
• In short, it's a set of bootstrapping scripts to turn a vanilla OpenBSD install into a feature-rich gateway device
• It also makes use of Ansible playbooks for configuration, allowing for a more "mass deployment" type of setup
• Everything is configured via a simple text file, and you end up with a local NTP server, DHCP server, firewall (obviously) and local caching DNS resolver - it even does DNSSEC validation
• All the code is open source and on Github, so you can read through what's actually being changed and put in place
• There's also a video guide to the entire process, if you're more of a visual person ***

OPNsense 15.1.10 released

• Speaking of BSD routers, if you're looking for a "prebuilt and ready to go" option, OPNsense has just released a new version
• 15.1.10 drops some of the legacy patches they inherited from pfSense, aiming to stay closer to the mainline FreeBSD source code
• Going along with this theme, they've redone how they do ports, and are now kept totally in sync with the regular ports tree
• Their binary packages are now signed using the fingerprint-style method, various GUI menus have been rewritten and a number of other bugs were fixed
• NanoBSD-based images are also available now, so you can try it out on hardware with constrained resources as well
• Version 15.1.10.1 was released shortly thereafter, including a hotfix for VLANs ***

IBM Workpad Z50 and NetBSD

• Before the infamous netbook fad came and went, IBM had a handheld PDA device that looked pretty much the same
• Back in 1999, they released the Workpad Z50 with Windows CE, sporting a 131MHz MIPS CPU, 16MB of RAM and a 640x480 display
• You can probably tell where this is going... the article is about installing NetBSD it
• "What prevents me from taking my pristine Workpad z50 to the local electronics recycling facility is NetBSD. With a little effort it is possible to install recent versions of NetBSD on the Workpad z50 and even have XWindows running"
• The author got pkgsrc up and running on it too, and cleverly used distcc to offload the compiling jobs to something a bit more modern
• He's also got a couple videos of the bootup process and running Xorg (neither of which we'd call "speedy" by any stretch of the imagination) ***

FreeBSD from the trenches

• The FreeBSD foundation has a new blog post up in their "from the trenches" series, detailing FreeBSD in some real-world use cases
• In this installment, Glen Barber talks about how he sets up all his laptops with ZFS and GELI
• While the installer allows for an automatic ZFS layout, Glen notes that it's not a one-size-fits-all thing, and goes through doing everything manually
• Each command is explained, and he walks you through the process of doing an encrypted installation on your root zpool ***

Broadwell in DragonFly

• DragonFlyBSD has officially won the race to get an Intel Broadwell graphics driver
• Their i915 driver has been brought up to speed with Linux 3.14's, adding not only Broadwell support, but many other bugfixes for other cards too
• It's planned for commit to the main tree very soon, but you can test it out with a git branch for the time being ***

Feedback/Questions

• Bostjan writes in
• Hunter writes in
• Hrishi writes in
• Clint writes in
• Sergei writes in ***

Mailing List Gold

• How did you guess ***

This episode was brought to you by

Interview - Pawel Jakub Dawidek - pjd@freebsd.org

Porting ZFS, GEOM, GELI, Capsicum, various topics

This episode was brought to you by

Headlines

BSDCan 2014 talks and reports

• The majority of the BSDCan talks are finally uploaded, so prepare to be flooded with links
• Karl Lehenbauer's keynote (he's on next week's episode)
• Mariusz Zaborski and Pawel Jakub Dawidek, Capsicum and Casper (relevant to today's interview)
• Luigi Rizzo, In-kernel OpenvSwitch on FreeBSD
• Dwayne Hart, Migrating from Linux to FreeBSD for Backend Data Storage
• Warner Losh, NAND Flash and FreeBSD
• Simon Gerraty, FreeBSD bmake and Meta Mode
• Bob Beck, LibreSSL - The First 30 Days
• Henning Brauer, OpenBGPD Turns 10 Years Old
• Arun Thomas, BSD ARM Kernel Internals
• Peter Hessler, Using BGP for Realtime Spam Lists
• Pedro Giffuni, Features and Status of FreeBSD's Ext2 Implementation
• Matt Ahrens, OpenZFS Upcoming Features and Performance Enhancements
• Daichi Goto, Shellscripts and Commands
• Benno Rice, Keeping Current
• Sean Bruno, MIPS Router Hacking
• John-Mark Gurney, Optimizing GELI Performance
• Patrick Kelsey, Userspace Networking with libuinet
• Massimiliano Stucchi, IPv6 Transitioning Mechanisms
• Roger Pau Monné, Taking the Red Pill
• Shawn Webb, Introducing ASLR in FreeBSD
• There's also a trip report from Peter Hessler and one from Julio Merino
• The latter report also talks about how, unfortunately, NetBSD basically had no presence in the event at all (and how that's a recurring trend) ***

Defend your network and privacy with a VPN and OpenBSD

• After all the recent news about spying, backdoored routers, deep packet inspection and everything else, you might want to start taking steps at getting some privacy back
• This article describes how to set up a secure network gateway and VPN using OpenBSD and related crypto utilities
• There are bits for DHCP, DNS, OpenVPN, DNSCrypt and a watchdog script to make sure your tunnel is always being used
• You can transparently tunnel all your outbound traffic over the VPN with this configuration, nothing is needed on any of the client systems - this could also be used with Tor (but it would be very slow)
• It also includes a few general privacy tips, recommended browser extensions, etc
• The intro to the article is especially great, so give the whole thing a read
• He mentions our OpenBSD router guide and other tutorials being a big help for this setup, so hello if you're watching! ***

You should try FreeBSD

• In this blog post, the author talks a bit about how some Linux people aren't familiar with the BSDs and how we can take steps to change that
• He goes into some FreeBSD history specifically, then talks about some of the apparent (and not-so-apparent) differences between the two
• Possibly the most useful part is how to address the question "my server already works, why bother switching?"
• "Stackoverflow’s answers assume I have apt-get installed"
• It includes mention of the great documentation, stability, ports, improved security and much more
• A takeaway quote for would-be Linux switchers: "I like to compare FreeBSD to a really tidy room where you can find everything with your eyes closed. Once you know where the closets are, it is easy to just grab what you need, even if you have never touched it before" ***

OpenBSD and the little Mauritian contributor

• This is a story about a guy from Mauritius named Logan, one of OpenBSD's newest developers
• Back in 2010, he started sending in patched for OpenBSD's "mg" editor, among other small things, and eventually added file transfer resume support for SFTP
• The article talks about his journey from just a guy who submits a patch here and there to joining the developer ranks and even getting his picture taken with Theo at a recent hackathon
• It really shows how easy it is to get involved with the different BSDs and contribute back to the software ecosystem
• Congrats to Logan, and hopefully this will inspire more people to start helping out and contributing code back ***

Interview - Jon Anderson - jonathan@freebsd.org

Capsicum and Casperd

Tutorial

Encrypting DNS lookups

News Roundup

FreeBSD Journal, May 2014 issue

• The newest issue of the FreeBSD Journal is out, following the bi-monthly release cycle
• This time the topics include: a letter from the foundation, a ports report, some 9.3-RELEASE plans, an events calendar, an overview of ipfw, exploring network activity with dtrace, an article about kqueue, data distribution with dnssec and finally an article about TCP scaling
• Pick up your (digital) copy at Amazon, Google Play or on iTunes and have a read ***

LibreSSL porting update

• Since the last LibreSSL post we covered, a couple unofficial "portable" versions have died off
• Unfortunately, people still think they can just port LibreSSL to other BSDs and Linux all willy-nilly - stop doing that!
• This post reiterates that LibreSSL currently relies on a lot of OpenBSD-specific security functions that are not present in other systems, and also gives a very eye-opening example
• Please wait for an official portable version instead of wasting time with these dime-a-dozen github clones that do more harm than good ***

BSDMag May 2014 issue is out

• The usual monthly release from BSDMag, covering a variety of subjects
• This time around the topics include: managing large development projects using RCS, working with HAMMER FS and PFSes, running MeteorJS on FreeBSD 11, another bhyve article, more GIMP tutorials and a few other things
• It's a free PDF, go grab it ***

BSDTalk episode 241

• A new episode of BSDTalk is out, this time with Bob Beck
• He talks about the OpenBSD foundation's recent activities, his own work in the project, some stories about the hardware in Theo's basement and a lot more
• The interview itself isn't about LibreSSL at all, but they do touch on it a bit too
• Really interesting stuff, covers a lot of different topics in a short amount of time ***

Feedback/Questions

• We got a number of replies about last week's VPN question, so thanks to everyone who sent in an email about it - the vpnc package seems to be what we were looking for
• Tim writes in
• AJ writes in
• Peter writes in
• Thomas writes in
• Martin writes in ***