November saw a number of improvements to HardenedBSD. Loic fixed a bunch of old cruft in base. Among the changes from Loic:

1. Remove Oliver Pinter's old kernel config
2. Clean up line breaks
3. Fix the motd generation code to use HardenedBSD's motd template
4. Bug fixes in hbsd-update
5. Use HTTPS with hbsd-update (possible now that FreeBSD distributs trusted CA root certificates.)

I need to MFC a bunch of his work to 13-STABLE and 12-STABLE where applicable.

The HardenedBSD Foundation's Ben La Monica has been stellar at keeping our self-hosted GitLab up-to-date and making sure that runs smoothly.

FreeBSD updated llvm in 14-CURRENT base to llvm 13. I've been working on addressing the fallout from that. Note that though there is fallout, it's the good kind: the llvm compiler toolchain is progressing and finding buggy code. The problem comes when you build 30,000+ packages. ;-)

Speaking of building packages, the 14-CURRENT/amd64 package build server experienced a catastrophic failure. Just today (30 Nov 2021), I went into the datacenter to rebuild the server. 14-CURRENT/amd64 packages will lag behind for a little bit while I transfer backed up config files and the like and kick off a new build.

The 14-CURRENT/arm64 package builder is also in a paused state. I'm working on bisecting one or more commits from FreeBSD that trigger a kernel panic on the ThunderX1.

We also purchased and received another ThunderX1. This new TX1 will be used for development purposes (for example: porting SafeStack to HardenedBSD/arm64). The TX1 referenced in the paragraph above is solely for package builds. The git bisect is being performed on this second TX1. I've yet to find the offending commit(s), but hope to by the end of this coming weekend.

To better facilitate expansion and development efforts, I have installed a new 25U rack at home, which is where the second TX1 currently lives. My employer (BlackhawkNest, Inc, who graciously hosts the HardenedBSD build infrastructure) recently installed a third rack. We have a few servers to deploy into it, which will likely happen mid-December.

I'd like to take a moment to thank the wider HardenedBSD community. Your help and support is not only crucial to the project, but immensely appreciated. Contributions come in all forms, some of which are advocacy, patch submissions, monetary donations, and community support. Every contribution, no matter the form, helps the project grow. Especially as we enter the last month of the year, we are incredibly grateful for your continued support.

If you have an itch to scratch, please do! We review all patches for the project that come our way, regardless of whether they're security-related or not.

As a reminder, for those who create new accounts on our self-hosted GitLab, please email netops{AT}hardenedbsd{DOT}org for account activation.

October was pretty quiet. This status may seem a bit more random.

I spent more time learning llvm's compiler toolchain, focusing specifically on llvm-readobj. For those following along, here's FreeBSD's exp-run of enabling WITH_LLVM_TOOLCHAIN in base: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258872

I followed a few FreeBSD commits that affected HardenedBSD. Some of those commits deal with the signal trampoline code. Please let me know if you experience any oddities around signal delivery.

I've ordered a second ThunderX server for better arm64 support. The two SoftIron OverDrive 1000 systems the HardenedBSD Project has just don't deliver enough performance for doing operating systems development on.

Though it's not a part of the HardenedBSD project per se, I wrote a living article on my setup at home. Included are how I use HardenedBSD in several capacities, one being a PiHole alternative. I normally wouldn't include things of a personal nature in a HardenedBSD status update, but this article provides a decent peek into HardenedBSD's infrastructure. The link to the article: https://git.hardenedbsd.org/shawn.webb/articles/-/blob/master/personal/2...

This month was spent in writing utilities and libraries for HardenedBSD's infrastructure. I wrote a little library, called liblattzfs, to help our infrastructure monitoring daemon (hbsdmon) monitor the various ZFS pools on our systems. Though liblattzfs is developed out-of-tree, I've already merged it into the source tree.

I also worked on another library, liblattutil, to make it so that our applications can have one centralized logging API. It also has a nifty SQLite3 wrapper. One could use this wrapper to convert a SQLite3 query's result to JSON. :-)

I created a new little application (rync) to convert our every-six-hour auto-sync scripts from csh to C.

I also disabled CFI for wpa_supplicant. It's my hope that one day, I/we finally get Cross-DSO CFI working in base so that we can re-add CFI to some of these applications. I'm hoping to get back to Cross-DSO CFI work in the coming week.

FreeBSD released some securty advisories, so I made sure that we had binary updates released in a timely fashion. The package builds are still running.

FreeBSD updated ports-mgmt/pkg from 1.16.3 to 1.17.1, introducing some major changes that caused issues with our package repo. It took me a few days to find and resolve the issues. If anyone else notices any issues with the package repo itself, please let me know.

Loic reported an issue with randompid calculation, so I fixed that. He also fixed a few ports and researched the failures of a few others.

Overall, August was a month spent on HardenedBSD's auxiliary applications with the goal of enhanced stability.

liblattzfs: https://git.hardenedbsd.org/shawn.webb/liblattzfs
liblattutil: https://git.hardenedbsd.org/shawn.webb/liblattutil
rync: https://git.hardenedbsd.org/hardenedbsd/rync

HardenedBSD saw a lot of work in May 2021. Here are the most notable changes:

1. We hardened the kenv(2) syscall. Unprivileged or jailed users, even a jailed privileged account, should not be able to inspect the kernel environment. This is just one more hardening technique to mitigate "kernel infoleak as feature" type of issue.
2. We fixed an issue with our ASLR implementation interfering with FreeBSD's ASR implementation. This was due to a mismerge a while ago when FreeBSD made changes to their ASR implementation and we had to adjust ours in the ELF image activator.
3. We bumped bhyve's max vCPU count to 48 from 16. HardenedBSD's infrastructure now has systems with greater than 30 cores, so being arbitrarily limited to 16 meant we weren't utilizing the server to its greatest potential.
4. We hardened dumping non-dumpable memory mappings. FreeBSD implemented an interface to tell the kernel "even though this mapping has been marked as non-dumpable, go ahead and dump it when dumping a process' core."
5. FreeBSD's random stack gap implementation creates problems for certain applications, like ntpd. Rather than fix the issue, FreeBSD is explicitly disabling the stack gap for certain applications. We reverted those changes and are carrying on like normal.
6. We performed network maintenance. The build infrastructure's firewall is now directly connected to the internet, rather than being behind the corporate firewall. This should drastically help increase the robustness of the network, especially our IPv6 setup.
7. If you boot in UEFI mode, you'll notice a new bootloader screen. Thanks to Loic, HardenedBSD's logo should be nice and pretty on the UEFI bootloader screen.
8. Loic and I fixed some ports entries, getting errant ports to compile again in our package builds.
9. We're researching GitLab anti-spam measures. Ben La Monica from the HardenedBSD Foundation Board of Directors has been kindly maintaining our GitLab instance. We may experiment with different anti-spam measures and may experience minimal downtime as we do that research.
10. And for the big one: We now build (nearly) all of 14-CURRENT/amd64 world with LTO, including libraries. We introduced a new build configuration, MK_LTOLIB, to tell the build framework whether to build static/shared libraries with LTO. As a precursor to supporting Cross-DSO CFI, we must build as much of the base OS with LTO as possible. This gets us closer to our goal of an OS with Cross-DSO CFI fully enabled for the userland. The compiler toolchain, libthr, and the various bootloaders are NOT compiled with LTO. A set of one or more follow-up commits will enable LTO for arm64 as well. We're doing our first package build with amd64 as we speak. It will still be a while before we support Cross-DSO CFI, but this is a great step in the right direction.

I'm excited for the progress we're making. I'm grateful to serve the community and I'm more grateful for the community's support.

In April, HardenedBSD added a new developer named Loic! Loic is primarily focused on cleaning up old cruft in the HardenedBSD project and fixing bugs. It's my hope that, with time and increasing familiarity, he takes on more complex projects. Please join me in a warm welcome.

Just yesterday (30 Apr 2021), I set up the new 12-STABLE/amd64 nightly build server. After months of being offline, we are now building 12-STABLE every night again. I also updated all the servers/VMs/jails in our infrastructure.

I taught hbsd-update how to force IPv4 or IPv6. We now support the typical "-4" and "-6" options that most network applications support.

secadm is having issues right now. We're investigating the right fix. So, if you use secadm for toggling exploit mitigations, you'll probably want to use hbsd-control for now.