The first month of the year started strong. I'm going to get right into it.

In base:

1. FreeBSD landed their Virtual Dynamic Shared Object (VDSO) late last year. I brought those changes in to 14-CURRENT (and subsequently 13-STABLE). I ensured that the VDSO's userland mapping was still randomized. As it stands today, the VDSO is active on amd64, but not on arm64. I tested to make sure that both scenarios still work by testing on the development ThunderX1.
2. In the back port of the VDSO work to 13-STABLE, I introduced a single-character typo. I chased that down, squashing the bug.

FreeBSD's pkgbase work has advanced quite a bit. Our pkgbase integration didn't follow those advancements, so I belatedly fixed that. This was needed for work sponsored by BlackhawkNest, Inc.

3. Loic made it so that the kernel's config file isn't embedded in the kernel.
4. I made it so that we apply a separate delta for the RTLD upon image activation time. Previously, we would apply the same delta we use for regular mmap calls. Re-using the mmap delta placed the RTLD right next to the other dependent shared objects. As the RTLD contains high-value targets, applying a separate delta helps protect those targets.
5. I identified a problem with the OpenSSH import in base whereby the in-app sftpd service would crash when a Windows client attempted to connect. I resolved that issue by fixing a kernel check on the process control KPI.
6. FreeBSD introduced a new `security.bsd.allow_ptrace` sysctl node and its corresponding integration code. When PAX_HARDENING is set in the kernel (it is set by default), the sysctl node will default to 0.
7. CVE-2021-4034 came out. I took inspiration from OpenBSD's general mitigation of checking that (argc == 0) in the kernel before allowing execve(2) to complete. The implementation of the argc check differs between FreeBSD and HardenedBSD. FreeBSD's implementation occurs much sooner in the code path, whereas my implementation occurs after the sysentvec-specific sv_copyout_strings function pointer is called. Should there be a weird sv_copyout_strings implementation, our argc check will be more resilient than the FreeBSD check.
8. The old Berkely DataBase (bdb) implementation requires downstream consumers to reference function pointers in a contextual structure returned (and filled out) by dbopen(3). These function pointers point to uninstrumented functions in libc. Thus, when the cfi-icall scheme is applied, applications attempting to call those function pointers will be killed with SIGILL by CFI.
9. I spent around twenty hours this month on Cross-DSO CFI, the longest amount of time spent in a while. I've identified some chicken-and-egg scenarios, especially revolving around the dlopen dance in libc and the rtld. The Cross-DSO CFI runtime intercepts calls to dlopen in order to add the shared object's memory to the CFI allow list.

In ports:

1. Loic hardened the multimedia/ffmpeg port
2. I fixed the misc/seabios port.
3. Loic removed an unneeded patch in the security/osiris port.
4. I disabled the DTRACE option for a few ports. DTrace support is broken when using a more complete llvm compiler toolchain. I need to file a bug report upstream in llvm to address this, but haven't due to lack of time.
5. I fixed the openjdk ports.
6. Loic fixed the devel/aarch64-none-elf-gcc ports.
7. I disabled PaX MPROTECT for the mongodb ports.

Infrastructure work:

All of the HardenedBSD build infrastructure is graciously hosted by my employer, BlackhawkNest, Inc. Due to COVID-19, we're still working remotely 99.9% of the time, myself included. The 27th of this month was the first time in around three months since I had been in the office.

With my focus being more on the development side, I've not taken the time to set up a proper network and system monitoring solution. Some servers are experiencing hardware failures (mostly just dead drives).

Starting 02 Feb 2022, I plan to go up to the office at least twice per week. I've ordered replacement drives and will install them as soon as they arrive. The server hit hardest is the 12-STABLE nightly build server, which is at the point where I will need to rebuild it with new drives, performing a fresh reinstall and reconfiguration.

I plan to divert some of my development time towards infrastructure maintenance in February, setting up that infrastructure monitoring solution. I'd like to get us to the point where we can be anticipatory with our infrastructure's needs rather than reactionary.

Conclusion:

HardenedBSD has had a very busy and productive January. We've made several substantial improvements. This project would not be possible without the generous and greatly appreciated contributions of the community. The HardenedBSD team and I are grateful for the opportunity to serve you.

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.