NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

Allen K. Briggs Memorial Scholarship

Allen Briggs was one of the earliest members of the NetBSD community, pursuing his interest in macBSD, and moving to become a NetBSD developer when the two projects merged. Allen was known for his quiet and relaxed manner, and always brought a keen wisdom with him; allied with his acute technical expertise, he was one of the most valued members of the NetBSD community.
The Allen K. Briggs Memorial Scholarship is an endowment to provide scholarships in perpetuity for summer programs at the North Carolina School of Science & Math, which Allen considered to be a place that fundamentally shaped him as a person. We would love to invite Allen's friends and colleagues from the BSD community to donate to this cause so that we can provide more scholarships to students with financial need each year. We are approximately halfway to our goal of $50K with aspirations to exceed that target and fund additional scholarships.

Toward an automated tracking of OpenBSD ports contributions

A first step for the CI service would be to create a database of diffs sent to ports. This would allow people to track what has been sent and not yet committed and what the state of the contribution is (build/don’t build, apply/don’t apply).

---

News Roundup

Trying OpenZFS 2 on FreeBSD 12.2-RELEASE

OpenZFS 2 is a huge achievement, and makes me bullish about the long term prospects for the world’s most trustworthy and nicest to use storage system. You can even use try it today on FreeBSD 12.2-RELEASE, though I recommend tracking -CURRENT for these sorts of features.

---

OpenBSD on TECLAST F7 Plus

I got myself a TECLAST F7 Plus laptop. It comes preinstalled with Windows 10 but I planned to use it as my daily driver. So I installed OpenBSD 6.8 on it.

---

Multi-volume support in HAMMER2

• commit > This commit adds initial multi-volumes support for HAMMER2. Maximum supported volumes is 64. The feature and implementation is similar to multi-volumes support in HAMMER1. ***

Beastie Bits

• FreeBSD Last SVN Commit
• FreeBSD First git Commit
• Introducing OpenZFS 2.0 Webinar - Jan 20th @ noon Eastern / 17:00 UTC. ***

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

• jay - feedback for ian
• Iebluefire - concerns about freebsd
• mike - zfs cluster aware ***
• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

TrueNAS is Multi-OS

There was a time in history where all that mattered was an Operating System (OS) and the hardware it ran on — the “pre-software era”, if you will. Your hardware dictated the OS you used.
Once software applications became prominent, your hardware’s OS determined the applications you could run. Application vendors were forced to juggle the burden of “portability” between OS platforms, choosing carefully the operating systems they’d develop their software to. Then, there were the great OS Wars of the 1990s, replete with the rampant competition, licensing battles, and nasty lawsuits, which more or less gave birth to the “open source OS” era.
The advent of the hypervisor simultaneously gave way to the “virtual era” which set us on a path of agnosticism toward the OS. Instead of choosing from the applications available for your chosen OS, you could simply install another OS on the same hardware for your chosen application. The OS became nothing but a necessary cog in the stack.
TrueNAS open storage enables this “post-OS era” with support for storage clients of all UNIX flavors, Linux, FreeBSD, Windows, MacOS, VMware, Citrix, and many others. Containerization has carried that mentality even further. An operating system, like the hardware that runs it, is now just thought of as part of the “infrastructure”.

---

Encrypted ZFS on NetBSD 9.0, for a FreeBSD guy

I had one of my other HP Microservers brought back from the office last week to help with this working-from-home world we’re in right now. I was going to wipe an old version of Debian Wheezy/Xen and install FreeBSD to mirror my other machines before thinking: why not NetBSD?

---

News Roundup

FreeBSD's New Code of Conduct

• FreeBSD Announcement Email

Gaming on OpenBSD

While no one would expect this, there are huge efforts from a small team to bring more games into OpenBSD. In fact, now some commercial games works natively now, thanks to Mono or Java. There are no wine or linux emulation layer in OpenBSD.
Here is a small list of most well known games that run on OpenBSD:

---

'dig' a little deeper

I knew the existence of the dig command but didn't exactly know when and how to use it. Then, just recently I encountered an issue that allowed me to learn and make use of it.

---

HAMMER2 and periodic snapshots

The first version of HAMMER took automatic snapshots, set within the config for each filesystem. HAMMER2 now also takes automatic snapshots, via periodic(8) like most every repeating task on your DragonFly system.

• git: Implement periodic hammer2 snapshots ***

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

• Cy - OpenSSL relicensing
• Christian - lagg vlans and iocage
• Brad - SMR ***
• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

Headlines

The Earliest Unix Code: An Anniversary Source Code Release

What is it that runs the servers that hold our online world, be it the web or the cloud? What enables the mobile apps that are at the center of increasingly on-demand lives in the developed world and of mobile banking and messaging in the developing world? The answer is the operating system Unix and its many descendants: Linux, Android, BSD Unix, MacOS, iOS—the list goes on and on. Want to glimpse the Unix in your Mac? Open a Terminal window and enter “man roff” to view the Unix manual entry for an early text formatting program that lives within your operating system.

2019 marks the 50th anniversary of the start of Unix. In the summer of 1969, that same summer that saw humankind’s first steps on the surface of the Moon, computer scientists at the Bell Telephone Laboratories—most centrally Ken Thompson and Dennis Ritchie—began the construction of a new operating system, using a then-aging DEC PDP-7 computer at the labs.

This man sent the first online message 50 years ago

• As many of you have heard in the past, the first online message ever sent between two computers was "lo", just over 50 years ago, on Oct. 29, 1969.

It was supposed to say "log," but the computer sending the message — based at UCLA — crashed before the letter "g" was typed. A computer at Stanford 560 kilometres away was supposed to fill in the remaining characters "in," as in "log in."

• The CBC Radio show, “The Current” has a half-hour interview with the man who sent that message, Leonard Kleinrock, distinguished professor of computer science at UCLA

"The idea of the network was you could sit at one computer, log on through the network to a remote computer and use its services there,"

50 years later, the internet has become so ubiquitous that it has almost been rendered invisible. There's hardly an aspect in our daily lives that hasn't been touched and transformed by it.

Q: Take us back to that day 50 years ago. Did you have the sense that this was going to be something you'd be talking about a half a century later?

A: Well, yes and no. Four months before that message was sent, there was a press release that came out of UCLA in which it quotes me as describing what my vision for this network would become. Basically what it said is that this network would be always on, always available. Anybody with any device could get on at anytime from any location, and it would be invisible.

Well, what I missed ... was that this is going to become a social network. People talking to people. Not computers talking to computers, but [the] human element.

Q: Can you briefly explain what you were working on in that lab? Why were you trying to get computers to actually talk to one another?

A: As an MIT graduate student, years before, I recognized I was surrounded by computers and I realized there was no effective [or efficient] way for them to communicate. I did my dissertation, my research, on establishing a mathematical theory of how these networks would work. But there was no such network existing. AT&T said it won't work and, even if it does, we want nothing to do with it.

So I had to wait around for years until the Advanced Research Projects Agency within the Department of Defence decided they needed a network to connect together the computer scientists they were supervising and supporting.

Q: For all the promise of the internet, it has also developed some dark sides that I'm guessing pioneers like yourselves never anticipated.

A: We did not. I knew everybody on the internet at that time, and they were all well-behaved and they all believed in an open, shared free network. So we did not put in any security controls.

When the first spam email occurred, we began to see the dark side emerge as this network reached nefarious people sitting in basements with a high-speed connection, reaching out to millions of people instantaneously, at no cost in time or money, anonymously until all sorts of unpleasant events occurred, which we called the dark side.

But in those early days, I considered the network to be going through its teenage years. Hacking to spam, annoying kinds of effects. I thought that one day this network would mature and grow up. Well, in fact, it took a turn for the worse when nation states, organized crime and extremists came in and began to abuse the network in severe ways.

Q: Is there any part of you that regrets giving birth to this?

A: Absolutely not. The greater good is much more important.

News Roundup

How to use blacklistd(8) with NPF as a fail2ban replacement

blacklistd(8) provides an API that can be used by network daemons to communicate with a packet filter via a daemon to enforce opening and closing ports dynamically based on policy.

The interface to the packet filter is in /libexec/blacklistd-helper (this is currently designed for npf) and the configuration file (inspired from inetd.conf) is in etc/blacklistd.conf

Now, blacklistd(8) will require bpfjit(4) (Just-In-Time compiler for Berkeley Packet Filter) in order to properly work, in addition to, naturally, npf(7) as frontend and syslogd(8), as a backend to print diagnostic messages. Also remember npf shall rely on the npflog* virtual network interface to provide logging for tcpdump() to use.

Unfortunately (dont' ask me why ??) in 8.1 all the required kernel components are still not compiled by default in the GENERIC kernel (though they are in HEAD), and are rather provided as modules. Enabling NPF and blacklistd services would normally result in them being automatically loaded as root, but predictably on securelevel=1 this is not going to happen.

• FreeBSD’s handbook chapter on blacklistd

OpenBSD crossed 400,000 commits

Sometime in the last week OpenBSD crossed 400,000 commits (*) upon all our repositories since starting at 1995/10/18 08:37:01 Canada/Mountain. That's a lot of commits by a lot of amazing people.

(*) by one measure. Since the repository is so large and old, there are a variety of quirks including ChangeLog missing entries and branches not convertible to other repo forms, so measuring is hard. If you think you've got a great way of measuring, don't be so sure of yourself -- you may have overcounted or undercounted.

• Subject to the notes Theo made about under and over counting, FreeBSD should hit 1 million commits (base + ports + docs) some time in 2020
• NetBSD + pkgsrc are approaching 600,000, but of course pkgsrc covers other operating systems too

How to Install Bolt CMS with Nginx and Let's Encrypt on FreeBSD 12

Bolt is a sophisticated, lightweight and simple CMS built with PHP. It is released under the open-source MIT-license and source code is hosted as a public repository on Github. A bolt is a tool for Content Management, which strives to be as simple and straightforward as possible. It is quick to set up, easy to configure, uses elegant templates. Bolt is created using modern open-source libraries and is best suited to build sites in HTML5 with modern markup. In this tutorial, we will go through the Bolt CMS installation on FreeBSD 12 system by using Nginx as a web server, MySQL as a database server, and optionally you can secure the transport layer by using acme.sh client and Let's Encrypt certificate authority to add SSL support.

• Requirements
• The system requirements for Bolt are modest, and it should run on any fairly modern web server:
  • PHP version 5.5.9 or higher with the following common PHP extensions: pdo, mysqlnd, pgsql, openssl, curl, gd, intl, json, mbstring, opcache, posix, xml, fileinfo, exif, zip.
  • Access to SQLite (which comes bundled with PHP), or MySQL or PostgreSQL.
  • Apache with mod_rewrite enabled (.htaccess files) or Nginx (virtual host configuration covered below).
  • A minimum of 32MB of memory allocated to PHP.

hammer2 - Optimize hammer2 support threads and dispatch

Refactor the XOP groups in order to be able to queue strategy calls, whenever possible, to the same CPU as the issuer. This optimizes several cases and reduces unnecessary IPI traffic between cores. The next best thing to do would be to not queue certain XOPs to an H2 support thread at all, but I would like to keep the threads intact for later clustering work.

The best scaling case for this is when one has a large number of user threads doing I/O. One instance of a single-threaded program on an otherwise idle machine might see a slightly reduction in performance but at the same time we completely avoid unnecessarily spamming all cores in the system on the behalf of a single program, so overhead is also significantly lower.

This will tend to increase the number of H2 support threads since we need a certain degree of multiplication for domain separation.

This should significantly increase I/O performance for multi-threaded workloads.

You know, we might as well just run every network service over HTTPS/2 and build another six layers on top of that to appease the OSI 7-layer burrito guys

I've seen the writing on the wall, and while for now you can configure Firefox not to use DoH, I'm not confident enough to think it will remain that way. To that end, I've finally set up my own DoH server for use at Chez Boca. It only involved setting up my own CA to generate the appropriate certificates, install my CA certificate into Firefox, configure Apache to run over HTTP/2 (THANK YOU SO VERY XXXXX­XX MUCH GOOGLE FOR SHOVING THIS HTTP/2 XXXXX­XXX DOWN OUR THROATS!—no, I'm not bitter) and write a 150 line script that just queries my own local DNS, because, you know, it's more XXXXX­XX secure or some XXXXX­XXX reason like that.

Sigh.

Beastie Bits

• An Oral History of Unix
• NUMA Siloing in the FreeBSD Network Stack [pdf]
• EuroBSDCon 2019 videos available
• Barbie knows best
• For the #OpenBSD #e2k19 attendees. I did a pre visit today.
• Drawer Find
• Slides - Removing ROP Gadgets from OpenBSD - AsiaBSDCon 2019

Feedback/Questions

• Bostjan - Open source doesn't mean secure
• Malcolm - Allan is Correct.

• Michael - FreeNAS inside a Jail

  ---

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

FreeBSD and custom firmware on the Google Pixelbook

• FreeBSD and custom firmware on the Google Pixelbook

Back in 2015, I jumped on the ThinkPad bandwagon by getting an X240 to run FreeBSD on. Unlike most people in the ThinkPad crowd, I actually liked the clickpad and didn\u2019t use the trackpoint much. But this summer I\u2019ve decided that it was time for something newer. I wanted something..

• lighter and thinner (ha, turns out this is actually important, I got tired of carrying a T H I C C laptop - Apple was right all along);
• with a 3:2 display (why is Lenovo making these Serious Work\u2122 laptops 16:9 in the first place?? 16:9 is awful in below-13-inch sizes especially);
• with a HiDPI display (and ideally with a good size for exact 2x scaling instead of fractional);
• with USB-C ports;
• without a dGPU, especially without an NVIDIA GPU;
• assembled with screws and not glue (I don\u2019t necessarily need expansion and stuff in a laptop all that much, but being able to replace the battery without dealing with a glued chassis is good);
• supported by FreeBSD of course (\u201csome development required\u201d is okay but I\u2019m not going to write big drivers);
• how about something with open source firmware, that would be fun.

I was considering a ThinkPad X1 Carbon from an old generation - the one from the same year as the X230 is corebootable, so that\u2019s fun. But going back in processor generations just doesn\u2019t feel great. I want something more efficient, not less!

And then I discovered the Pixelbook. Other than the big huge large bezels around the screen, I liked everything about it. Thin aluminum design, a 3:2 HiDPI screen, rubber palm rests (why isn\u2019t every laptop ever doing that?!), the \u201cconvertibleness\u201d (flip the screen around to turn it into.. something rather big for a tablet, but it is useful actually), a Wacom touchscreen that supports a pen, mostly reasonable hardware (Intel Wi-Fi), and that famous coreboot support (Chromebooks\u2019 stock firmware is coreboot + depthcharge).

So here it is, my new laptop, a Google Pixelbook.

• Conclusion

Pixelbook, FreeBSD, coreboot, EDK2 good.

Seriously, I have no big words to say, other than just recommending this laptop to FOSS enthusiasts :)

Porting NetBSD to the AMD x86-64: a case study in OS portability

• Abstract

NetBSD is known as a very portable operating system, currently running on 44 different architectures (12 different types of CPU). This paper takes a look at what has been done to make it portable, and how this has decreased the amount of effort needed to port NetBSD to a new architecture. The new AMD x86-64 architecture, of which the specifications were published at the end of 2000, with hardware to follow in 2002, is used as an example.

• Portability

Supporting multiple platforms was a primary goal of the NetBSD project from the start. As NetBSD was ported to more and more platforms, the NetBSD kernel code was adapted to become more portable along the way.

• General

Generally, code is shared between ports as much as possible. In NetBSD, it should always be considered if the code can be assumed to be useful on other architectures, present or future. If so, it is machine-independent and put it in an appropriate place in the source tree. When writing code that is intended to be machine-independent, and it contains conditional preprocessor statements depending on the architecture, then the code is likely wrong, or an extra abstraction layer is needed to get rid of these statements.

• Types

Assumptions about the size of any type are not made. Assumptions made about type sizes on 32-bit platforms were a large problem when 64-bit platforms came around. Most of the problems of this kind had to be dealt with when NetBSD was ported to the DEC Alpha in 1994. A variation on this problem had to be dealt with with the UltraSPARC (sparc64) port in 1998, which is 64-bit, but big endian (vs. the little-endianness of the Alpha). When interacting with datastructures of a fixed size, such as on-disk metadata for filesystems, or datastructures directly interpreted by device hardware, explicitly sized types are used, such as uint32_t, int8_t, etc.

• Conclusions and future work

The port of NetBSD to AMD's x86-64 architecture was done in six weeks, which confirms NetBSD's reputation as being a very portable operating system. One week was spent setting up the cross-toolchain and reading the x86-64 specifications, three weeks were spent writing the kernel code, one week was spent writing the userspace code, and one week testing and debugging it all. No problems were observed in any of the machine-independent parts of the kernel during test runs; all (simulated) device drivers, file systems, etc, worked without modification.

News Roundup

ZFS performance really does degrade as you approach quota limits

Every so often (currently monthly), there is an "OpenZFS leadership meeting". What this really means is 'lead developers from the various ZFS implementations get together to talk about things'. Announcements and meeting notes from these meetings get sent out to various mailing lists, including the ZFS on Linux ones.

• In the September meeting notes, I read a very interesting (to me) agenda item:
  • Relax quota semantics for improved performance (Allan Jude)
  • Problem: As you approach quotas, ZFS performance degrades.
  • Proposal: Can we have a property like quota-policy=strict or loose, where we can optionally allow ZFS to run over the quota as long as performance is not decreased.

This is very interesting to me because of two reasons. First, in the past we have definitely seen significant problems on our OmniOS machines, both when an entire pool hits a quota limit and when a single filesystem hits a refquota limit. It's nice to know that this wasn't just our imagination and that there is a real issue here. Even better, it might someday be improved (and perhaps in a way that we can use at least some of the time).

Second, any number of people here run very close to and sometimes at the quota limits of both filesystems and pools, fundamentally because people aren't willing to buy more space. We have in the past assumed that this was relatively harmless and would only make people run out of space. If this is a known issue that causes serious performance degradation, well, I don't know if there's anything we can do, but at least we're going to have to think about it and maybe push harder at people. The first step will have to be learning the details of what's going on at the ZFS level to cause the slowdown. (It's apparently similar to what happens when the pool is almost full, but I don't know the specifics of that either.)

With that said, we don't seem to have seen clear adverse effects on our Linux fileservers, and they've definitely run into quota limits (repeatedly). One possible reason for this is that having lots of RAM and SSDs makes the effects mostly go away. Another possible reason is that we haven't been looking closely enough to see that we're experiencing global slowdowns that correlate to filesystems hitting quota limits. We've had issues before with somewhat subtle slowdowns that we didn't understand (cf), so I can't discount that we're having it happen again.

Fixing up KA9Q-unix, or "neck deep in 30 year old codebases.."

I'll preface this by saying - yes, I'm still neck deep in FreeBSD's wifi stack and 802.11ac support, but it turns out it's slow work to fix 15 year old locking related issues that worked fine on 11abg cards, kinda worked ok on 11n cards, and are terrible for these 11ac cards. I'll .. get there.

Anyhoo, I've finally been mucking around with AX.25 packet radio. I've been wanting to do this since I was a teenager and found out about its existence, but back in high school and .. well, until a few years ago really .. I didn't have my amateur radio licence. But, now I do, and I've done a bunch of other stuff with a bunch of other radios. The main stumbling block? All my devices are either Apple products or run FreeBSD - and none of them have useful AX.25 stacks. The main stacks of choice these days run on Linux, Windows or are a full hardware TNC.

So yes, I was avoiding hacking on AX.25 stuff because there wasn't a BSD compatible AX.25 stack. I'm 40 now, leave me be.

But! A few weeks ago I found that someone was still running a packet BBS out of San Francisco. And amazingly, his local node ran on FreeBSD! It turns out Jeremy (KK6JJJ) ported both an old copy of KA9Q and N0ARY-BBS to run on FreeBSD! Cool!

I grabbed my 2m radio (which is already cabled up for digital modes), compiled up his KA9Q port, figured out how to get it to speak to Direwolf, and .. ok. Well, it worked. Kinda.

HAMMER2 and fsck for review

HAMMER2 is Copy on Write, meaning changes are made to copies of existing data. This means operations are generally atomic and can survive a power outage, etc. (You should read up on it!) However, there\u2019s now a fsck command, useful if you want a report of data validity rather than any manual repair process.

[The return of startx(1) for non-root users with some caveats

Mark Kettenis (kettenis@) has recently committed changes which restore a certain amount of startx(1)/xinit(1) functionality for non-root users. The commit messages explain the situation:

CVSROOT:    /cvs
Module name:    src
Changes by:    kettenis@cvs.openbsd.org    2019/09/15 06:25:41

Modified files:
    etc/etc.amd64  : fbtab 
    etc/etc.arm64  : fbtab 
    etc/etc.hppa   : fbtab 
    etc/etc.i386   : fbtab 
    etc/etc.loongson: fbtab 
    etc/etc.luna88k: fbtab 
    etc/etc.macppc : fbtab 
    etc/etc.octeon : fbtab 
    etc/etc.sgi    : fbtab 
    etc/etc.sparc64: fbtab 

Log message:
Add ttyC4 to lost of devices to change when logging in on ttyC0 (and in some cases also the serial console) such that X can use it as its VT when running without root privileges.

ok jsg@, matthieu@
CVSROOT:    /cvs
Module name:    xenocara
Changes by:    kettenis@cvs.openbsd.org    2019/09/15 06:31:08

Modified files:
    xserver/hw/xfree86/common: xf86AutoConfig.c 

Log message:
Add modesetting driver as a fall-back when appropriate such that we can use it when running without root privileges which prevents us from scanning the PCI bus.

This makes startx(1)/xinit(1) work again on modern systems with inteldrm(4), radeondrm(4) and amdgpu(4).  In some cases this will result in using a different driver than with xenodm(4) which may expose issues (e.g. when we prefer the intel Xorg driver) or loss of acceleration (e.g. older cards supported by radeondrm(4)).

ok jsg@, matthieu@

Beastie Bits

• ASCII table and history. Or, why does Ctrl+i insert a Tab in my terminal?
• Sourcehut makes BSD software better
• Chaosnet for Unx
• The Vim-Inspired Editor with a Linguistic Twist
• bhyvearm64: CPU and Memory Virtualization on Armv8.0-A
• DefCon25 - Are all BSD created Equally - A Survey of BSD Kernel vulnerabilities

Feedback/Questions

• Tim - GSoC project ideas for pf rule syntax translation
• Brad - Steam on FreeBSD
• Ruslan - FreeBSD Quarterly Status Report - Q2 2019

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

Headlines

EuroBSDcon 2019 Recap

We’re back from EuroBSDcon in Lillehammer, Norway. It was a great conference with 212 people attending. 2 days of tutorials, parallel to the FreeBSD Devsummit, followed by two days of talks. Some speakers uploaded their slides to papers.freebsd.org already with more to come.

The social event was also interesting. We visited an open air museum with building preserved from different time periods. In the older section they had a collection of farm buildings, a church originally built in the 1200s and relocated to the museum, and a school house. In the more modern area, they had houses from 1915, and each decade from 1930 to 1990, plus a “house of the future” as imagined in 2001. Many had open doors to allow you to tour the inside, and some were even “inhabited”. The latter fact gave a much more interactive experience and we could learn additional things about the history of that particular house. The town at the end included a general store, a post office, and more. Then, we all had a nice dinner together in the museum’s restaurant.

• The opening keynote by Patricia Aas was very good. Her talk on embedded ethics, from her perspective as someone trying to defend the sanctity of Norwegian elections, and a former developer for the Opera web browser, provided a great deal of insight into the issues. Her points about how the tech community has unleashed a very complex digital work upon people with barely any technical literacy were well taken. Her stories of trying to explain the problems with involving computers in the election process to journalists and politicians struck a chord with many of us, who have had to deal with legislation written by those who do not truly understand the issues with technology.

Setting up buildbot in FreeBSD jails

In this article, I would like to present a tutorial to set up buildbot, a continuous integration (CI) software (like Jenkins, drone, etc.), making use of FreeBSD’s containerization mechanism "jails". We will cover terminology, rationale for using both buildbot and jails together, and installation steps. At the end, you will have a working buildbot instance using its sample build configuration, ready to play around with your own CI plans (or even CD, it’s very flexible!). Some hints for production-grade installations are given, but the tutorial steps are meant for a test environment (namely a virtual machine). Buildbot’s configuration and detailed concepts are not in scope here.

Setting up a mail server with OpenSMTPD, Dovecot and Rspamd

• Self-hosting and encouraging smaller providers is for the greater good

First of all, I was not clear enough about the political consequences of centralizing mail services at Big Mailer Corps.

It doesn’t make sense for Random Joe, sharing kitten pictures with his family and friends, to build a personal mail infrastructure when multiple Big Mailer Corps offer “for free” an amazing quality of service. They provide him with an e-mail address that is immediately available and which will generally work reliably. It really doesn’t make sense for Random Joe not to go there, and particularly if even techies go there without hesitation, proving it is a sound choice.

There is nothing wrong with Random Joes using a service that works.

What is terribly wrong though is the centralization of a communication protocol in the hands of a few commercial companies, EVERY SINGLE ONE OF THEM coming from the same country (currently led by a lunatic who abuses power and probably suffers from NPD), EVERY SINGLE ONE OF THEM having been in the news and/or in a court for random/assorted “unpleasant” behaviors (privacy abuses, eavesdropping, monopoly abuse, sexual or professional harassment, you just name it…), and EVERY SINGLE ONE OF THEM growing user bases that far exceeds the total population of multiple countries combined.

News Roundup

The HamBSD project aims to bring amateur packet radio to OpenBSD

The HamBSD project aims to bring amateur packet radio to OpenBSD, including support for TCP/IP over AX.25 and APRS tracking/digipeating in the base system.

HamBSD will not provide a full AX.25 stack but instead only implement support for UI frames. There will be a focus on simplicity, security and readable code.

The amateur radio community needs a reliable platform for packet radio for use in both leisure and emergency scenarios. It should be expected that the system is stable and resilient (but as yet it is neither).

DragonFlyBSD's HAMMER2 Gets Basic FSCK Support

HAMMER2 is Copy on Write, meaning changes are made to copies of existing data. This means operations are generally atomic and can survive a power outage, etc. (You should read up on it!) However, there’s now a fsck command, useful if you want a report of data validity rather than any manual repair process.

• commit

Add initial fsck support for HAMMER2, although CoW fs doesn't require fsck as a concept. Currently no repairing (no write), just verifying.

Keep this as a separate command for now.
https://i.redd.it/vkdss0mtdpo31.jpg

---

The return of startx for users

Add modesetting driver as a fall-back when appropriate such that we can use it when running without root privileges which prevents us from scanning the PCI bus.

This makes startx(1)/xinit(1) work again on modern systems with inteldrm(4), radeondrm(4) and amdgpu(4). In some cases this will result in using a different driver than with xenodm(4) which may expose issues (e.g. when we prefer the intel Xorg driver) or loss of acceleration (e.g. older cards supported by radeondrm(4)).

Beastie Bits

• Ori Bernstein will be giving the October talk at NYCBUG
• BSD Pizza Night: 2019/09/26, 7–9PM, Portland, Oregon, USA
• Nick Wolff : Home Lab Show & Tell
• Installing the Lumina Desktop in DragonflyBSD
• dhcpcd 8.0.6 added

Feedback/Questions

• Bruce - FOSDEM videos
• Lars - Super Cluster of BSD on Rock64Pr
• Madhukar - Question

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

Headlines

OPNsense 19.7.1

We do not wish to keep you from enjoying your summer time, but this
is a recommended security update enriched with reliability fixes for the
new 19.7 series. Of special note are performance improvements as well
as a fix for a longstanding NAT before IPsec limitation.

Full patch notes:

• system: do not create automatic copies of existing gateways
• system: do not translate empty tunables descriptions
• system: remove unwanted form action tags
• system: do not include Syslog-ng in rc.freebsd handler
• system: fix manual system log stop/start/restart
• system: scoped IPv6 "%" could confuse mwexecf(), use plain mwexec() instead
• system: allow curl-based downloads to use both trusted and local authorities
• system: fix group privilege print and correctly redirect after edit
• system: use cached address list in referrer check
• system: fix Syslog-ng search stats
• firewall: HTML-escape dynamic entries to display aliases
• firewall: display correct IP version in automatic rules
• firewall: fix a warning while reading empty outbound rules configuration
• firewall: skip illegal log lines in live log
• interfaces: performance improvements for configurations with hundreds of interfaces
• reporting: performance improvements for Python 3 NetFlow aggregator rewrite
• dhcp: move advanced router advertisement options to correct config section
• ipsec: replace global array access with function to ensure side-effect free boot
• ipsec: change DPD action on start to "dpdaction = restart"
• ipsec: remove already default "dpdaction = none" if not set
• ipsec: use interface IP address in local ID when doing NAT before IPsec
• web proxy: fix database reset for Squid 4 by replacing use of ssl_crtd with security_file_certgen
• plugins: os-acme-client 1.24[1]
• plugins: os-bind 1.6[2]
• plugins: os-dnscrypt-proxy 1.5[3]
• plugins: os-frr now restricts characters BGP prefix-list and route-maps[4]
• plugins: os-google-cloud-sdk 1.0[5]
• ports: curl 7.65.3[6]
• ports: monit 5.26.0[7]
• ports: openssh 8.0p1[8]
• ports: php 7.2.20[9]
• ports: python 3.7.4[10]
• ports: sqlite 3.29.0[11]
• ports: squid 4.8[12]

Stay safe and hydrated, Your OPNsense team

ZFS on Linux still has annoying issues with ARC size

One of the frustrating things about operating ZFS on Linux is that the ARC size is critical but ZFS's auto-tuning of it is opaque and apparently prone to malfunctions, where your ARC will mysteriously shrink drastically and then stick there.

Linux's regular filesystem disk cache is very predictable; if you do disk IO, the cache will relentlessly grow to use all of your free memory. This sometimes disconcerts people when free reports that there's very little memory actually free, but at least you're getting value from your RAM. This is so reliable and regular that we generally don't think about 'is my system going to use all of my RAM as a disk cache', because the answer is always 'yes'. (The general filesystem cache is also called the page cache.)

This is unfortunately not the case with the ZFS ARC in ZFS on Linux (and it wasn't necessarily the case even on Solaris). ZFS has both a current size and a 'target size' for the ARC (called 'c' in ZFS statistics). When your system boots this target size starts out as the maximum allowed size for the ARC, but various events afterward can cause it to be reduced (which obviously limits the size of your ARC, since that's its purpose). In practice, this reduction in the target size is both pretty sticky and rather mysterious (as ZFS on Linux doesn't currently expose enough statistics to tell why your ARC target size shrunk in any particular case).

The net effect is that the ZFS ARC is not infrequently quite shy and hesitant about using memory, in stark contrast to Linux's normal filesystem cache. The default maximum ARC size starts out as only half of your RAM (unlike the regular filesystem cache, which will use all of it), and then it shrinks from there, sometimes very significantly, and once shrunk it only recovers slowly (if at all).

News Roundup

Hammer2 is now default

commit a49112761c919d42d405ec10252eb0553662c824
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date:   Mon Jun 10 17:53:46 2019 -0700

    installer - Default to HAMMER2

    * Change the installer default from HAMMER1 to HAMMER2.

    * Adjust the nrelease build to print the location of the image files
      when it finishes.

Summary of changes:
 nrelease/Makefile                          |  2 +-
 usr.sbin/installer/dfuibe_installer/flow.c | 20 ++++++++++----------
 2 files changed, 11 insertions(+), 11 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/a49112761c919d42d405ec10252eb0553662c824

NetBSD audio – an application perspective

NetBSD audio – an application perspective ... or, "doing it natively, because we can"

• audio options for NetBSD in pkgsrc

  • Use NetBSD native audio (sun audio/audioio.h)
  • Or OSS emulation layer: Basically a wrapper around sun audio in the kernel. Incomplete and old version, but works for simple stuff

• Many many abstraction layers available:

  • OpenAL-Soft
  • alsa-lib (config file required)
  • libao, GStreamer (plugins!)
  • PortAudio, SDL
  • PulseAudio, JACK
  • ... lots more!? some obsolete stuff (esd, nas?)

• Advantages of using NetBSD audio directly

  • Low latency, low CPU usage: Abstraction layers differ in latency (SDL2 vs ALSA/OpenAL)
  • Query device information: Is /dev/audio1 a USB microphone or another sound card?
  • Avoid bugs from excessive layering
  • Nice API, well documented: [nia note: I had no idea how to write audio code. I read a man page and now I do.]
  • Your code might work on illumos too

• [nia note: SDL2 seems very sensitive to the blk_ms sysctl being high or low, with other implementations there seems to be a less noticable difference. I don't know why.]

New FreeNAS Mini

Two new FreeNAS Mini systems join the very popular FreeNAS Mini and Mini XL:

FreeNAS Mini XL+: This powerful 10 Bay platform (8x 3.5” and 1x 2.5” hot-swap, 1x 2.5” internal) includes the latest, compact server technology and provides dual 10GbE ports, 8 CPU cores and 32 GB RAM for high performance workgroups. The Mini XL+ scales beyond 100TB and is ideal for very demanding applications, including hosting virtual machines and multimedia editing. Starting at $1499, the Mini XL+ configured with cache SSD and 80 TB capacity is $4299, and consumes about 100 Watts.

FreeNAS Mini E: This cost-effective 4 Bay platform provides the resources required for SOHO use with quad GbE ports and 8 GB of RAM. The Mini E is ideal for file sharing, streaming and transcoding video at 1080p. Starting at $749, the Mini E configured with 8 TB capacity is $999, and consumes about 36 Watts.

Beastie Bits

• Welcome to NetBSD 9.99.1!
• Berkeley smorgasbord — part II
• dtracing postgres
• Project Trident 19.07-U1 now available
• Need a Secure Operating System? Take a Look at OpenBSD

Feedback/Questions

• Jeff - OpenZFS Port Testing Feedback
• Malcolm - Best Practices for Custom Ports
• Michael - Little Correction

• 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 ***

##Headlines
###Assembly language on OpenBSD amd64+arm64

This is a short introduction to assembly language programming on OpenBSD/amd64+arm64. Because of security features in the kernel, I have had to rethink a series of tutorials covering Aarch64 assembly language on OpenBSD, and therefore this will serve as a placeholder-cum-reminder.

OpenBSD, like many UNIX and unix-like operating systems, now uses the Executable and Linkable Format (ELF) for its binary libraries and executables. Although the structure of this format is beyond the scope of this short introduction, it is necessary for me to explain part of one of the headers.

Within the program header there are sections known as PT_NOTE that OpenBSD and other systems use to distinguish their ELF executables - OpenBSD looks for this section to check if it should attempt to execute the program or not.

• Our first program: in C!

It’s often a good idea to prototype your assembly programs in a high level language such as C - it can then double up as both a set of notes and a working program that you can debug and compile into assembly language to compare with your own asm code.

• See the article for the rest on:
• Our first program: in x86-64 Asm (AT&T/GAS syntax)
• Our first program: in inline x86-64 assembly
• Our first program: in x86-64 asm (NASM syntax)
• Our first program: in ARMv8 AArch64 assembly

###Using bhyve for FreeBSD Development

• The Hypervisor

The bhyve hypervisor requires a 64-bit x86 processor with hardware support for virtualization. This requirement allows for a simple, clean hypervisor implementation, but it does require a fairly recent
processor. The current hypervisor requires an Intel processor, but there is an active development branch with support for AMD processors.
The hypervisor itself contains both user and kernel components. The kernel driver is contained in the vmm.ko module and can be loaded either at boot from the boot loader or at runtime. It must
be loaded before any guests can be created. When a guest is created, the kernel driver creates a device file in /dev/vmm which is used by the user programs to interact with the guest.
The primary user component is the bhyve(8) program. It constructs the emulated device tree in the guest and provides the implementation for most of the emulated devices. It also calls the kernel driver to execute the guest. Note that the guest always executes inside the driver itself, so guest execution time in the host is counted as system time in the bhyve process.
Currently, bhyve does not provide a system firmware interface to the guest (neither BIOS nor UEFI). Instead, a user program running on the host is used to perform boot time operations including loading the guest operating system kernel into the guest’s memory and setting the initial guest state so that the guest begins execution at the kernel’s entry point. For FreeBSD guests, the bhyveload(8) program can be used to load the kernel and prepare the guest for execution. Support for some other operating systems is available via the grub2-bhyve program which is available via the sysutils/grub2-bhyve port or as a prebuilt package.
The bhyveload(8) program in FreeBSD 10.0 only supports 64-bit guests. Support for 32-bit guests will be included in FreeBSD 10.1.

• See the article for the very technical breakdown of the following:

• Network Setup

• Bridged Configuration

• Private Network with NAT

• Using dnsmasq with a Private Network

• Running Guests via vmrun.sh

• Configuring Guests

• Using a bhyve Guest as a Target

• Conclusion

The bhyve hypervisor is a nice addition to a FreeBSD developer’s toolbox. Guests can be used both to develop new features and to test merges to stable branches. The hypervisor has a wide variety of uses beyond developing FreeBSD as well.

##News Roundup
###Games on FreeBSD

What do all programmers like to do after work? Ok, what do most programers like to do after work? The answer is simple: play a good game! Recently at the Polish BSD User Group meetup mulander was telling us how you can play games on OpenBSD. Today let’s discuss how this looks in the FreeBSD world using the “server only” operating system.

• XNA based games

One of the ways of playing natively is to play indie games which use XNA. XNA is a framework from Microsoft which uses .NET, for creating games. Fortunately, in the BSD world we have Mono, an open source implementation of Microsoft’s .NET Framework which you can use to run games. There is also FNA framework which is a reimplementation of XNA which allows you to run the games under Linux. Thomas Frohwein, from OpenBSD, prepared a script, fnaify. Fnaify translate all dependencies used by an FNA game to OpenBSD dependencies.
I decided to port the script to FreeBSD. The script is using /bin/sh which in the case of OpenBSD is a Korn Shell.

I didn’t test it with many games, but I don’t see any reason why it shouldn’t work with all the games tested by the OpenBSD guys. For example, with:

• Cryptark

• Rouge Legacy

• Apotheon

• Escape Goat

• Bastion

• CrossCode

• Atom Zombie Smasher

• Open-Source games

In FreeBSD and OpenBSD we also will find popular games which were open sourced. For example, I spend a lot of time playing in Quake 3 Arena on my FreeBSD machine. You can very simply install it using pkg: # pkg install ioquake3

Then move the files for the skins and maps to the .ioquake3 directory from your copy of Quake. In the past I also played UrbanTerror which is a fully open source shooter based on the Quake 3 Arena engine. It’s is also very easy to install it from ports: # pkg install iourbanterror

In the ports tree in the games directory you can find over 1000 directories, many of them with fully implemented games. I didn’t test many games in this category, but you can find some interesting titles like:

• openxcom (Open-source re-implementation of the original X-Com)
• openjazz (Free re-implementation of the Jazz Jackrabbit™ game engine)
• corsixth (Open source re-implementation of Theme Hospital)
• quake2
• openra (Red Alert)
• openrct2 (Open source re-implementation of RollerCoaster Tycoon 2)
• openmw (Open source engine reimplementation of the game Morrowind)

All those titles are simply installed through the packages. In that case I don’t think FreeBSD has any difference from OpenBSD.

• Wine

One of the big advantages of FreeBSD over OpenBSD is that FreeBSD supports wine. Wine allows you to run Windows applications under other operating systems (including mac). If you are a FreeBSD 11 user, you can simply fetch wine from packages: # pkg install i386-wine

To run Windows games, you need to have a 32-bit wine because most of the games on Windows are built on 32-bits (maybe this has changed – I don’t play so much these days). In my case, because I run FreeBSD-CURRENT I needed to build wine from ports. It wasn’t nice, but it also wasn’t unpleasant. The whole step-by-step building process of a wine from ports can be found here.

• Summary

As you can see there are many titles available for *BSDs. Thanks to the FNA and fnaify, OpenBSD and FreeBSD can work with indie games which use the XNA framework. There are many interesting games implemented using this framework. Open source is not only for big server machines, and there are many re-implementations of popular games like Theme Hospital or RollerCoaster Tycoon 2. The biggest market is still enabled through wine, although its creates a lot of problems to run the games. Also, if you are an OpenBSD user only this option is not available for you. Please also note that we didn’t discuss any other emulators besides wine. In OpenBSD and FreeBSD there are many of them for GameBoy, SNES, NeoGeo and other games consoles.

###FreeBSD For Thanksgiving

I’ve been working on FreeBSD for Intel for almost 6 months now. In the world of programmers, I am considered an old dog, and these 6 months have been all about learning new tricks. Luckily, I’ve found myself in a remarkably inclusive and receptive community whose patience seems plentiful. As I get ready to take some time off for the holidays, and move into that retrospective time of year, I thought I’d beat the rush a bit and update on the progress
Earlier this year, I decided to move from architect of the Linux graphics driver into a more nebulous role of FreeBSD enabling. I was excited, but also uncertain if I was making the right decision.
Earlier this half, I decided some general work in power management was highly important and began working there. I attended BSDCam (handsome guy on the right), and led a session on Power Management. I was honored to be able to lead this kind of effort.
Earlier this quarter, I put the first round of my patches up for review, implementing suspend-to-idle. I have some rougher patches to handle s0ix support when suspending-to-idle. I gave a talk MeetBSD about our team’s work.
Earlier this month, I noticed that FreeBSD doesn’t have an implementation for Intel Speed Shift (HWPstates), and I started working on that.
Earlier this week, I was promoted from a lowly mentee committer to a full src committer.
Earlier today, I decided to relegate my Linux laptop to the role of my backup machine, and I am writing this from my Dell XPS13 running FreeBSD

vandamme 13.0-CURRENT FreeBSD 13.0-CURRENT #45 881fee072ff(hwp)-dirty: Mon Nov 19 16:19:32 PST 2018 bwidawsk@vandamme:/usr/home/bwidawsk/usr/obj/usr/home/bwidawsk/usr/src/amd64.amd64/sys/DEVMACHINE amd64

6 months later, I feel a lot less uncertain about making the right decision. In fact, I think both opportunities would be great, and I’m thankful this Thanksgiving that this is my life and career. I have more plans and things I want to get done. I’m looking forward to being thankful again next year.

###hammer2: no space left on device on Dragonfly BSD

• The Issue

hammer2 does not actually delete a file when you rm or unlink it. Since recovery of the file is possible (this is the design of hammer2), there will still be an entry taking up data. It’s similar to how git works.
Even with 75% usage listed here, the filesystem could still have filled up. If you are using it as your root filesystem, then attempts to clean up data may fail. If the kernel panics over this, you will see something like this.

• The Fix

If you have a recent enough version of the rescue ramdisk installed, on bootup you can press ‘r’ and access the rescue ramdisk. Your provider will have to offer some sort of remote interface for interacting with the operating system before it boots, like VNC or IPMI. You can then mount your filesystem using:

[root@ ~]# mkdir /tmp/fs
[root@ ~]# mount_hammer2 -o local /dev/vbd0s1a /tmp/fs

If you receive an error that /sbin/hammer2 is not found, then your rescue ramdisk is not up to date enough. In that scenario, download the latest 5.2 iso from dragonflybsd.org and boot from the cd-rom on your virtual machine or physical device. Just login as root instead of installer.
If the mount does succeed, then all you have to do is run the following twice:

[root@ ~]# /sbin/hammer2 bulkfree /tmp/fs

If you do not have enough memory on your machine, you may need to mount swap. Add your swap partition to the /etc/fstab and then do:

[root@ ~]# swapon -a

Once you have ran the bulkfree command twice, the usage reported by df -h will be correct. However, there is a chance on reboot that a core dump will be placed in /var/crash/ so be prepared to have plenty of space free in case that happens. You should also delete any files you can and run the bulkfree operation twice afterwards to clear up additional space.

##Beastie Bits

• BSD Pizza Night - Portland
• bsd@35c3: …the place for you…*NIX!
• Project Trident PreRelease Image now available
• Play Stardew Valley on OpenBSD
• GUI Wrapper for OpenBSD mixerctl
• qtv - QuickTextViewer

##Feedback/Questions

• Ron - Ideas for feedback section
• Paulo - SDIO Firmware
• Dan - Some fun ZFS questions about labels

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

Headlines

DragonFlyBSD: release52 (w/stable HAMMER2, as default root)

• DragonflyBSD 5.2.1 was released on May 21, 2018
• > Big Ticket items:

  Meltdown and Spectre mitigation support Meltdown isolation and spectre mitigation support added. Meltdown mitigation is automatically enabled for all Intel cpus. Spectre mitigation must be enabled manually via sysctl if desired, using sysctls machdep.spectremitigation and machdep.meltdownmitigation. HAMMER2 H2 has received a very large number of bug fixes and performance improvements. We can now recommend H2 as the default root filesystem in non-clustered mode. Clustered support is not yet available. ipfw Updates Implement state based "redirect", i.e. without using libalias. ipfw now supports all possible ICMP types. Fix ICMPMAXTYPE assumptions (now 40 as of this release). Improved graphics support The drm/i915 kernel driver has been updated to support Intel Coffeelake GPUs Add 24-bit pixel format support to the EFI frame buffer code. Significantly improve fbio support for the "scfb" XOrg driver. This allows EFI frame buffers to be used by X in situations where we do not otherwise support the GPU. Partly implement the FBIOBLANK ioctl for display powersaving. Syscons waits for drm modesetting at appropriate places, avoiding races.

PS4 4.55 BPF Race Condition Kernel Exploit Writeup

Note: While this bug is primarily interesting for exploitation on the PS4, this bug can also potentially be exploited on other unpatched platforms using FreeBSD if the attacker has read/write permissions on /dev/bpf, or if they want to escalate from root user to kernel code execution. As such, I've published it under the "FreeBSD" folder and not the "PS4" folder.

• Introduction

Welcome to the kernel portion of the PS4 4.55FW full exploit chain write-up. This bug was found by qwerty, and is fairly unique in the way it's exploited, so I wanted to do a detailed write-up on how it worked. The full source of the exploit can be found here. I've previously covered the webkit exploit implementation for userland access here.

• FreeBSD or Sony's fault? Why not both...

Interestingly, this bug is actually a FreeBSD bug and was not (at least directly) introduced by Sony code. While this is a FreeBSD bug however, it's not very useful for most systems because the /dev/bpf device driver is root-owned, and the permissions for it are set to 0600 (meaning owner has read/write privileges, and nobody else does) - though it can be used for escalating from root to kernel mode code execution. However, let’s take a look at the make_dev() call inside the PS4 kernel for /dev/bpf (taken from a 4.05 kernel dump).

seg000:FFFFFFFFA181F15B lea rdi, unk_FFFFFFFFA2D77640 seg000:FFFFFFFFA181F162 lea r9, aBpf ; "bpf" seg000:FFFFFFFFA181F169 mov esi, 0 seg000:FFFFFFFFA181F16E mov edx, 0 seg000:FFFFFFFFA181F173 xor ecx, ecx seg000:FFFFFFFFA181F175 mov r8d, 1B6h seg000:FFFFFFFFA181F17B xor eax, eax seg000:FFFFFFFFA181F17D mov cs:qword_FFFFFFFFA34EC770, 0 seg000:FFFFFFFFA181F188 call make_dev

We see UID 0 (the UID for the root user) getting moved into the register for the 3rd argument, which is the owner argument. However, the permissions bits are being set to 0x1B6, which in octal is 0666. This means anyone can open /dev/bpf with read/write privileges. I’m not sure why this is the case, qwerty speculates that perhaps bpf is used for LAN gaming. In any case, this was a poor design decision because bpf is usually considered privileged, and should not be accessible to a process that is completely untrusted, such as WebKit. On most platforms, permissions for /dev/bpf will be set to 0x180, or 0600.

• Race Conditions - What are they?

The class of the bug abused in this exploit is known as a "race condition". Before we get into bug specifics, it's important for the reader to understand what race conditions are and how they can be an issue (especially in something like a kernel). Often in complex software (such as a kernel), resources will be shared (or "global"). This means other threads could potentially execute code that will access some resource that could be accessed by another thread at the same point in time. What happens if one thread accesses this resource while another thread does without exclusive access? Race conditions are introduced.

Race conditions are defined as possible scenarios where events happen in a sequence different than the developer intended which leads to undefined behavior. In simple, single-threaded programs, this is not an issue because execution is linear. In more complex programs where code can be running in parallel however, this becomes a real issue. To prevent these problems, atomic instructions and locking mechanisms were introduced. When one thread wants to access a critical resource, it will attempt to acquire a "lock". If another thread is already using this resource, generally the thread attempting to acquire the lock will wait until the other thread is finished with it. Each thread must release the lock to the resource after they're done with it, failure to do so could result in a deadlock.

While locking mechanisms such as mutexes have been introduced, developers sometimes struggle to use them properly. For example, what if a piece of shared data gets validated and processed, but while the processing of the data is locked, the validation is not? There is a window between validation and locking where that data can change, and while the developer thinks the data has been validated, it could be substituted with something malicious after it is validated, but before it is used. Parallel programming can be difficult, especially when, as a developer, you also want to factor in the fact that you don't want to put too much code in between locking and unlocking as it can impact performance.

• See article for the rest

iXsystems

Remote Debugging the running OpenBSD kernel

• Subtitled: A way to understand the OpenBSD internals +> The Problem +> A few month ago, I tried porting the FreeBSD kdb along with it's gdb stub implementations to OpenBSD as a practice of learning the internals of an BSD operating system. The ddb code in both FreeBSD and OpenBSD looks pretty much the same and the GDB Remote Serial Protocol looks very minimal. +> But sadly I got very busy and the work is stalled but I'm planning on resuming the attempt as soon as I get the chance, But there is an alternative way to Debugging the OpenBSD kernel via QEMU. What I did below is basically the same with a few minor changes which I hope to describe it as best. +> Installing OpenBSD on Qemu +> For debugging the kernel, we need a working OpenBSD system running on Qemu. I chose to create a raw disk file to be able to easily mount it later via the host and copy the custom kernel onto it.

  $ qemu-img create -f raw disk.raw 5G $ qemu-system-x8664 -m 256M \ -drive format=raw,file=install63.fs \ -drive format=raw,file=disk.raw +> Custom Kernel +> To debug the kernel, we need a version of the kernel with debugging symbols and for that we have to recompile it first. The process is documented at Building the System from Source: ... +> Then we can copy the bsd kernel to the guest machine and keep the bsd.gdb on the host to start the remote debugging via gdb. +> Remote debugging kernel +> Now it's to time to boot the guest with the new custom kernel. Remember that the -s argument enables the gdb server on qemu on localhost port 1234 by default: $ qemu-system-x8664 -m 256M -s \ -net nic -net user \ -drive format=raw,file=install63.fs \ +> Now to finally attach to the running kernel:

Interview - Patrick Mooney - Software Engineer pmooney@pfmooney.com / @pfmooney

• BR: How did you first get introduced to UNIX?
• AJ: What got you started contributing to an open source project?
• BR: What sorts of things have you worked on in the past?
• AJ: Can you tell us more about what attracted you to illumos?
• BR: How did you get interested in, and started with, systems development?
• AJ: When did you first get interested in bhyve?
• BR: How much work was it to take the years-old port of bhyve and get it working on modern IllumOS?
• AJ: What was the process for getting the bhyve port caught up to current FreeBSD?
• BR: How usable is bhyve on illumOS?
• AJ: What area are you most interested in improving in bhyve?
• BR: Do you think the FreeBSD and illumos versions of bhyve will stay in sync with each other?
• AJ: What do you do for fun?
• BR: Anything else you want to mention?

News Roundup

Setting up buildbot in FreeBSD Jails

In this article, I would like to present a tutorial to set up buildbot, a continuous integration (CI) software (like Jenkins, drone, etc.), making use of FreeBSD’s containerization mechanism "jails". We will cover terminology, rationale for using both buildbot and jails together, and installation steps. At the end, you will have a working buildbot instance using its sample build configuration, ready to play around with your own CI plans (or even CD, it’s very flexible!). Some hints for production-grade installations are given, but the tutorial steps are meant for a test environment (namely a virtual machine). Buildbot’s configuration and detailed concepts are not in scope here.

• Table of contents

  • Choosing host operating system and version for buildbot
  • Create a FreeBSD playground
  • Introduction to jails
  • Overview of buildbot
  • Set up jails
  • Install buildbot master
  • Run buildbot master
  • Install buildbot worker
  • Run buildbot worker
  • Set up web server nginx to access buildbot UI
  • Run your first build
  • Production hints
  • Finished!

• Choosing host operating system and version for buildbot

We choose the released version of FreeBSD (11.1-RELEASE at the moment). There is no particular reason for it, and as a matter of fact buildbot as a Python-based server is very cross-platform; therefore the underlying OS platform and version should not make a large difference.

It will make a difference for what you do with buildbot, however. For instance, poudriere is the de-facto standard for building packages from source on FreeBSD. Builds run in jails which may be any FreeBSD base system version older or equal to the host’s version (reason will be explained below). In other words, if the host is FreeBSD 11.1, build jails created by poudriere could e.g. use 9.1, 10.3, 11.0, 11.1, but potentially not version 12 or newer because of incompatibilities with the host’s kernel (jails do not run their own kernel as full virtual machines do). To not prolong this article over the intended scope, the details of which nice things could be done or automated with buildbot are not covered.

Package names on the FreeBSD platform are independent of the OS version, since external software (as in: not part of base system) is maintained in FreeBSD ports. So, if your chosen FreeBSD version (here: 11) is still officially supported, the packages mentioned in this post should work. In the unlikely event of package name changes before you read this article, you should be able to find the actual package names like pkg search buildbot.

Other operating systems like the various Linux distributions will use different package names but might also offer buildbot pre-packaged. If not, the buildbot installation manual offers steps to install it manually. In such case, the downside is that you will have to maintain and update the buildbot modules outside the stability and (semi-)automatic updates of your OS packages.

• See article for the rest

DigitalOcean

Dumping your USB

One of the many new features of OpenBSD 6.3 is the possibility to dump USB traffic to userland via bpf(4). This can be done with tcpdump(8) by specifying a USB bus as interface:

```

tcpdump: listening on usb0, link-type USBPCAP 12:28:03.317945 bus 0 < addr 1: ep1 intr 2 0000: 0400 ..

12:28:03.318018 bus 0 > addr 1: ep0 ctrl 8 0000: 00a3 0000 0002 0004 00 .........
[...] ```

As you might have noted I decided to implement the existing USBPcap capture format. A capture format is required because USB packets do not include all the necessary information to properly interpret them. I first thought I would implement libpcap's DLTUSB but then I quickly realize that this was not a standard. It is instead a FreeBSD specific format which has been since then renamed DLTUSBFREEBSD. But I didn't want to embrace xkcd #927, so I look at the existing formats: DLTUSBFREEBSD, DLTUSBLINUX, DLTUSBLINUXMMAPPED, DLTUSBDARWIN and DLT_USBPCAP. I was first a bit sad to see that nobody could agree on a common format then I moved on and picked the simplest one: USBPcap. Implementing an already existing format gives us out-of-box support for all the tools supporting it. That's why having common formats let us share our energy. In the case of USBPcap it is already supported by Wireshark, so you can already inspect your packet graphically. For that you need to first capture raw packets:

```

tcpdump: listening on usb0, link-type USBPCAP ^C 208 packets received by filter 0 packets dropped by kernel ```

USB packets can be quite big, that's why I'm not using tcpdump(8)'s default packet size. In this case, I want to make sure I can dump the complete uaudio(4) frames. It is important to say that what is dumped to userland is what the USB stack sees. Packets sent on the wire might differ, especially when it comes to retries and timing. So this feature is not here to replace any USB analyser, however I hope that it will help people understand how things work and what the USB stack is doing. Even I found some interesting timing issues while implementing isochronous support.

Run OpenBSD on your web server

• Deploy and login to your OpenBSD server first.

As soon as you're there you can enable an httpd(8) daemon, it's already installed on OpenBSD, you just need to configure it:

www# vi /etc/httpd.conf

• Add two server sections---one for www and another for naked domain (all requests are redirected to www).

``` server "www.example.com" { listen on * port 80 root "/htdocs/www.example.com" }

server "example.com" { listen on * port 80 block return 301 "http://www.example.com$REQUEST_URI" } ```

• httpd is chrooted to /var/www by default, so let's make a document root directory:

www# mkdir -p /var/www/htdocs/www.example.com

• Save and check this configuration:

www# httpd -n configuration ok

• Enable httpd(8) daemon and start it.

www# rcctl enable httpd www# rcctl start httpd

• Publish your website

• Copy your website content into /var/www/htdocs/www.example.com and then test it your web browser.

http://XXX.XXX.XXX.XXX/

Your web server should be up and running.

• Update DNS records

If there is another HTTPS server using this domain, configure that server to redirect all HTTPS requests to HTTP.

Now as your new server is ready you can update DNS records accordingly.

example.com. 300 IN A XXX.XXX.XXX.XXX www.example.com. 300 IN A XXX.XXX.XXX.XXX

• Examine your DNS is propagated.

$ dig example.com www.example.com

• Check IP addresses it answer sections. If they are correct, you should be able to access your new web server by its domain name.

• What's next? Enable HTTPS on your server.

Modern Akonadi and KMail on FreeBSD

For, quite literally a year or more, KMail and Akonadi on FreeBSD have been only marginally useful, at best. KDE4 era KMail was pretty darn good, but everything after that has had a number of FreeBSD users tearing out their hair. Sure, you can go to Trojitá, which has its own special problems and is generally “meh”, or bail out entirely to webmail, but .. KMail is a really great mail client when it works. Which, on Linux desktops, is nearly always, and on FreeBSD, is was nearly never.

I looked at it with Dan and Volker last summer, briefly, and we got not much further than “hmm”. There’s a message about “The world is going to end!” which hardly makes sense, it means that a message has been truncated or corrupted while traversing a UNIX domain socket.

Now Alexandre Martins — praise be! — has wandered in with a likely solution. KDE Bug 381850 contains a suggestion, which deserves to be publicised (and tested):

sysctl net.local.stream.recvspace=65536 sysctl net.local.stream.sendspace=65536

The default FreeBSD UNIX local socket buffer space is 8kiB. Bumping the size up to 64kiB — which matches the size that Linux has by default — suddenly makes KMail and Akonadi shine again. No other changes, no recompiling, just .. bump the sysctls (perhaps also in /etc/sysctl.conf) and KMail from Area51 hums along all day without ending the world.

Since changing this value may have other effects, and Akonadi shouldn’t be dependent on a specific buffer size anyway, I’m looking into the Akonadi code (encouraged by Dan) to either automatically size the socket buffers, or to figure out where in the underlying code the assumption about buffer size lives. So for now, sysctl can make KMail users on FreeBSD happy, and later we hope to have things fully automatic (and if that doesn’t pan out, well, pkg-message exists).

PS. Modern KDE PIM applications — Akonadi, KMail — which live in the deskutils/ category of the official FreeBSD ports were added to the official tree April 10th, so you can get your fix now from the official tree.

Beastie Bits

• pkg-provides support for DragonFly (from Rodrigo Osorio)
• Memories of writing a parser for man pages
• Bryan Cantrill interview over at DeveloperOnFire podcast
• 1978-03-25 - 2018-03-25: 40 years BSD Mail
• My 5 years of FreeBSD gaming: a compendium of free games and engines running natively on FreeBSD
• Sequential Resilver being upstreamed to FreeBSD, from FreeNAS, where it was ported from ZFS-on-Linux
• University of Aberdeen’s Internet Transport Research Group is hiring

Tarsnap ad

Feedback/Questions

• Dave - mounting non-filesystem things inside jails
• Morgan - ZFS on Linux Data loss bug
• Rene - How to keep your ISP’s nose out of your browser history with encrypted DNS
• Rodriguez - Feedback question! Relating to Windows

• 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

Solaris' networking future is with OpenBSD

• A curious patch from someone with an Oracle email address was recently sent in to one of the OpenBSD mailing lists
• It was revealed that future releases of Solaris are going to drop their IPFilter firewall entirely, in favor of a port of the current version of PF
• For anyone unfamiliar with the history of PF, it was actually made as a replacement for IPFilter in OpenBSD, due to some licensing issues
• What's more, Solaris was the original development platform for IPFilter, so the fact that it would be replaced in its own home is pretty interesting
• This blog post goes through some of the backstory of the two firewalls
• PF is in a lot of places - other BSDs, Mac OS X and iOS - but there are plenty of other OpenBSD-developed technologies end up ported to other projects too
• "Many of the world's largest corporations and government agencies are heavy Solaris users, meaning that even if you're neither an OpenBSD user or a Solaris user, your kit is likely interacting intensely with both kinds, and with Solaris moving to OpenBSD's PF for their filtering needs, we will all be benefiting even more from the OpenBSD project's emphasis on correctness, quality and security"
• You're welcome, Oracle ***

BAFUG discussion videos

• The Bay Area FreeBSD users group has been uploading some videos from their recent meetings
• Sean Bruno gave a recap of his experiences at EuroBSDCon last year, including the devsummit and some proposed ideas from it (as well as their current status)
• Craig Rodrigues also gave a talk about Kyua and the FreeBSD testing framework
• Lastly, Kip Macy gave a talk titled "network stack changes, user-level FreeBSD"
• The main two subjects there are some network stack changes, and how to get more people contributing, but there's also open discussion about a variety of FreeBSD topics
• If you're close to the Bay Area in California, be sure to check out their group and attend a meeting sometime ***

More than just a makefile

• If you're not a BSD user just yet, you might be wondering how the various ports and pkgsrc systems compare to the binary way of doing things on Linux
• This blog entry talks about the ports system in OpenBSD, but a lot of the concepts apply to all the ports systems across the BSDs
• As it turns out, the ports system really isn't that different from a binary package manager - they are what's used to create binary packages, after all
• The author goes through what makefiles do, customizing which options software is compiled with, patching source code to build and getting those patches back upstream
• After that, he shows you how to get your new port tested, if you're interesting in doing some porting yourself, and getting involved with the rest of the community
• This post is very long and there's a lot more to it, so check it out (and more discussion on Hacker News) ***

Securing your home fences

• Hopefully all our listeners have realized that trusting your network(s) to a consumer router is a bad idea by now
• We hear from a lot of users who want to set up some kind of BSD-based firewall, but don't hear back from them after they've done it.. until now
• In this post, someone goes through the process of setting up a home firewall using OPNsense on a PCEngines APU board
• He notes that you have a lot of options software-wise, including vanilla FreeBSD, OpenBSD or even Linux, but decided to go with OPNsense because of the easy interface and configuration
• The post covers all the hardware you'll need, getting the OS installed to a flash drive or SD card and going through the whole process
• Finally, he goes through setting up the firewall with the graphical interface, applying updates and finishing everything up
• If you don't have any experience using a serial console, this guide also has some good info for beginners about those (which also applies to regular FreeBSD)
• We love super-detailed guides like this, so everyone should write more and send them to us immediately ***

Interview - Pascal Stumpf - pascal@openbsd.org

Static PIE in OpenBSD

News Roundup

LLVM's new libFuzzer

• We've discussed fuzzing on the show a number of times, albeit mostly with the American Fuzzy Lop utility
• It looks like LLVM is going to have their own fuzzing tool too now
• The Clang and LLVM guys are no strangers to this type of code testing, but decided to "close the loop" and start fuzzing parts of LLVM (including Clang) using LLVM itself
• With Clang being the default in both FreeBSD and Bitrig, and with the other BSDs considering the switch, this could make for some good bug hunting across all the projects in the future ***

HardenedBSD upgrades secadm

• The HardenedBSD guys have released a new version of their secadm tool, with the showcase feature being integriforce support
• We covered both the secadm tool and integriforce in previous episodes, but the short version is that it's a way to prevent files from being altered (even as root)
• Their integriforce feature itself has also gotten a couple improvements: shared objects are now checked too, instead of just binaries, and it uses more caching to speed up the whole process now ***

RAID5 returns to OpenBSD

• OpenBSD's softraid subsystem, somewhat similar to FreeBSD's GEOM, has had experimental RAID5 support for a while
• However, it was exactly that - experimental - and required a recompile to enable
• With some work from recent hackathons, the final piece was added to enable resuming partial array rebuilds
• Now it's on by default, and there's a call for testing being put out, so grab a snapshot and put the code through its paces
• The bioctl softraid command also now supports DUIDs during pseudo-device detachment, possibly paving the way for the installer to drop the "do you want to enable DUIDs?" question entirely ***

pkgng 1.5.0 released

• Going back to what we talked about last week, the final version of pkgng 1.5.0 is out
• The "provides" and "requires" support is finally in a regular release
• A new "-r" switch will allow for direct installation to a chroot or alternate root directory
• Memory usage should be much better now, and some general code speed-ups were added
• This version also introduces support for Mac OS X, NetBSD and EdgeBSD - it'll be interesting to see if anything comes of that
• Many more bugs were fixed, so check the mailing list announcement for the rest (and plenty new bugs were added, according to bapt) ***

p2k15 hackathon reports

• There was another OpenBSD hackathon that just finished up in the UK - this time it was mainly for ports work
• As usual, the developers sent in reports of some of the things they got done at the event
• Landry Breuil, both an upstream Mozilla developer and an OpenBSD developer, wrote in about the work he did on the Firefox port (specifically WebRTC) and some others, as well as reviewing lots of patches that were ready to commit
• Stefan Sperling wrote in, detailing his work with wireless chipsets, specifically when the vendor doesn't provide any hardware documentation, as well as updating some of the games in ports
• Ken Westerback also sent in a report, but decided to be a rebel and not work on ports at all - he got a lot of GPT-related work done, and also reviewed the RAID5 support we talked about earlier ***

Feedback/Questions

• Shaun writes in
• Hrishi writes in
• Randy writes in
• Zach writes in
• Ben writes in ***

Mailing List Gold

• Gstreamer hates us
• At least he's honest
• I find myself in a situation ***

This episode was brought to you by

Headlines

OpenBSD on a Sun T5120

• Our buddy Ted Unangst got himself a cool Sun box
• Of course he had to write a post about installing and running OpenBSD on it
• The post goes through some of the quirks and steps to go through in case you're interested in one of these fine SPARC machines
• He's also got another post about OpenBSD on a Dell CS24-SC server ***

Bhyvecon 2014 videos are up

• Like we mentioned last week, Bhyvecon was an almost-impromptu conference before AsiaBSDCon
• The talks have apparently already been uploaded!
• Subjects include Bhyve's past, present and future, OSv on Bhyve, a general introduction to the tool, migrating those last few pesky Linux boxes to virtualization
• Lots more detail in the videos, so check 'em all out ***

Building a FreeBSD wireless access point

• We've got a new blog post about creating a wireless access point with FreeBSD
• After all the recent news of consumer routers being pwned like candy, it's time for people to start building BSD routers
• The author goes through a lot of the process of getting one set up using good ol' FreeBSD
• Using hostapd, he's able to share his wireless card in hostap mode and offer DHCP to all the clients
• Plenty of config files and more messy details in the post ***

Switching from Synology to FreeNAS

• The author has been considering getting a NAS for quite a while and documents his research
• He was faced with the compromise of convenience vs. flexibility - prebuilt or DIY
• After seeing the potential security issues with proprietary NAS devices, and dealing with frustration with trying to get bugs fixed, he makes the right choice
• The post also goes into some detail about his setup, all the things he needed a NAS to do as well as all the advantages an open source solution would give ***

Interview - Warren Block - wblock@freebsd.org

FreeBSD's documentation project, igor, doceng

Tutorial

The world of BSD mailing lists

News Roundup

HAMMER2 work and notes

• Matthew Dillon has posted some updated notes about the development of the new HAMMER version
• The start of a cluster API was committed to the tree
• There are also links to design document, a freemap design document, a changes list and a todo list ***

BSD Breaking Barriers

• Our friend MWL gave a talk at NYCBSDCon about BSD "breaking barriers"
• "What makes the BSD operating systems special? Why should you deploy your applications on BSD? Why does the BSD community keep growing, and why do Linux sites like DistroWatch say that BSD is where the interesting development work is happening? We'll cover the not-so-obvious reasons why BSD still stands tall after almost 40 years."
• He also has another upcoming talk, (or "webcast") called "Beyond Security: Getting to Know OpenBSD's Real Purpose"
• "OpenBSD is frequently billed as a high-security operating system. That's true, but security isn't the OpenBSD Project's main goal. This webcast will introduce systems administrators to OpenBSD, explain the project's mission, and discuss the features and benefits."
• It's on May 27th and will hopefully be recorded ***

FreeBSD in a chroot

• Finch, "FreeBSD running IN a CHroot," is a new project
• It's a way to extend the functionality of restricted USB-based FreeBSD systems (FreeNAS, etc.)
• All the details and some interesting use cases are on the github page
• He really needs to change the project name though ***

PCBSD weekly digest

• Lots of bugfixes for PCBSD coming down the tubes
• LZ4 compression is now enabled by default on the whole pool
• The latest 10-STABLE has been imported and builds are going
• Also the latest GNOME and Cinnamon builds have been imported and much more ***

Feedback/Questions

• Bostjan writes in (IRC suggests md5deep)
• Don writes in
• kaltheat writes in (We use R0DE Podcast microphones and Logitech C920 HD webcams)
• Harri writes in ***