HardenedBSD March 2022 Status Report

We made some cool progress in March. Though I, Shawn, am writing this report, I'll refer to myself in the third person for the rest of the report. :-)

In src:

  1. Shawn reverted a potential LPE race condition in ZFS introduced by OpenZFS. Only 14-CURRENT was affected.
  2. Shawn merged in zlib's CVE-2018-25032 fix.
  3. Shawn enabled -ftrivial-auto-var-init=zero in base clang by default. This now means we don't need to pass in any compiler flags to support this feature. All ports that rely on the system compiler will now automatically benefit.
  4. FreeBSD introduced a change that enables dumpon to use the underlying non-encrypted swap device when encrypted swap is used. Shawn reverted this change since users who choose to encrypt their swap encrypt it for a reason--HardenedBSD should proactively protect users by respecting their encryption preferences.
  5. Loic found and fixed an issue with the linuxulator in HardenedBSD, with the default stack permissions.
  6. Coming up soon: sponsored work by BlackhawkNest, Inc that provides support in base for (more) easily building HardenedBSD 13-STABLE based versions of OPNsense. This is in the hopes to provide the wider community with the ability to produce their own builds. Some of this work has landed in a special feature branch.

In ports:

  1. In tandem with src change #3, Shawn modified the ports tree to rely on the system compiler's application of -ftrivial-auto-var-init=zero. There's no need to apply that feature via CFLAGS injection.
  2. Loic removed `stackautoinit:off` USE_HARDENING flag from a very large number of ports. This was a huge lift and his work on this is very much appreciated. He and Shawn worked a lot on this.
  3. Ibrahim Kaikaa (Mr.UNIX) has helped fix a number of ports. We still have a number of outstanding merge requests that I need to verify.


  1. The HardenedBSD GitLab server had a drive failure. I had already planned to rebuild the pool from a bunch of older 1TB spinning rust drives to a bunch of 2TB SSDs. The drive failure accellerated the pool rebuild, which completed successfully.
  2. After a large number of months of downtime, our arm64 package building server has come back online! We're now building 14-CURRENT/arm64 packages.
  3. After src change #3 landed, all of the build infrastructure servers were updated.

Cool projects:

  1. Loic released an unofficial livecd of HardenedBSD that boots into XFCE[0]. I've started the discussion with him to convert that from from an "unofficial" project to an "official" one. :-)

Special notes:

  1. As a reminder, support for HardenedBSD 12-STABLE will be delegated to the community. As such, binary updates and package builds will cease. The hardened/12-stable/master branch will no longer be auto-synced.
  2. Please remember to let us know if you have any thoughts to share on whether HardenedBSD should support the linuxulator by 15 Apr 2022.
  3. Please remember to let us know if you have any thoughts to share on the proposed changes to the default sshd configuration[1].

[0]: https://groups.google.com/a/hardenedbsd.org/g/users/c/QUTUJfm30Dg/m/0VNK...
[1]: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/merge_requests/60

HardenedBSD January 2022 Status Report

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.
  3. 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.

  4. Loic made it so that the kernel's config file isn't embedded in the kernel.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.


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.

HardenedBSD December 2021 Status Report

It has been a busy December! I worked on 14-CURRENT/arm64 support. HardenedBSD now builds (nearly) all of world (both libraries and applications) with Link-Time Optimization (LTO). We now have two ThunderX1 systems. Over the past few months, FreeBSD introduced one or more commits that is causing the ThunderX1 system we use for package builds to fail to boot. Oddly, the other ThunderX1 server (used for arm64 development, rather than package builds) boots just fine. I've been working on tracking down which commit(s) are the culprit, but doing so takes time.

FreeBSD also landed a proper VDSO implementation. However, the implementation lacks ASLR support. Due to scheduling issues, I've reverted the VDSO-related commits until I have a solid weekend to hack on it, applying our PaX-inspired ASLR implementation to it. I hope to have that time mid-January or early February.

I narrowed down a few more issues in ports related to our switch to a more complete LLVM compiler toolchain. There are still a large number of ports to fix, which stands as a testament that the development community relies heavily on a GNU-based toolchain. Ideally, projects shouldn't care what toolchain is being used.

Loic landed ClonOS support in the HardenedBSD ports tree. He also helped address more LLVM toolchain fallout. I have a number of merge requests to review from him. Keep up the good work, Loic!

On Sunday (26 Dec 2021), I plan to work on HardenedBSD financials. I'm a bit late in sending out the typical "would you like to be listed on our donor's page" emails. I hope to also work on a 2022 project roadmap.

HardenedBSD has had a lot of help in 2021. The community's contributions have directly improved HardenedBSD. We received a number of server donations, which enables us to build packages quicker and more reliably. We were able to expand our arm64 support. All donations have gone to support either hardware or the few monthly expenses we have. I am grateful for any contribution, no matter the form it comes in--whether that's advocacy, patch submissions, monetary donations, hardware donations, etc. Your generosity enables the success of this project.

HardenedBSD November 2021 Status Report

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.

Call For Testing: Removing and hardening sensitive files

I've merged into a feature branch (hardened/current/sensitive) a merge request from Loic that hardens file and directory permissions for a handful of files/directories.

I plan to let the feature branch soak for around two months, giving the HardenedBSD community time to test the changes prior to them landing. Of course, should issues arise, we'll take care of them.

I've enabled binary updates for that feature branch and I've configured the auto-sync application to sync the branch along with all the other branches every six hours.

The feature branch will share the same package repo as hardened/current/master (aka, HardenedBSD 14-CURRENT). If you track 14-CURRENT, please help test the hardened/current/sensitive branch.

Attached to this email are the two hbsd-update config files: one for normal hbsd-update users, and another for Tor users.

HardenedBSD October 2021 Status Report

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...

HardenedBSD September 2021 Status Report

September saw a few changes. Most notably, in 14-CURRENT, FreeBSD introduced WITH_LLVM_BINUTILS, which we switched to. This makes it so that we use more llvm compiler toolchain tools, like llvm-objcopy, llvm-size, llvm-cxxfilt, etc. This causes a large number of ports to either fail or be skipped. Most notably, ports that include explicit DTrace support. I'm (slowly) learning how these extra llvm tools work to try to figure out how to fix these issues.

I hardened TCP and UDP blackholing (the `net.inet.tcp.blackhole` and `net.inet.udp.blackhole` sysctl nodes) such that connection attempts to unbound ports are ignored; that is, no TCP RST packet or ICMP unreach packets are sent on unbound ports.

I worked a bit on documentation, too. So the main project wiki is more up-to-date with regards to our features and changes. There's still more work to be done, but our documentation is indeed improving.

Loic troubleshooted some kernel panics and worked with FreeBSD to get those fixed. I still need to review a few patches he has submitted. I hope to get to that in the first week in October.

We received a new server donation. The server will be dedicated for Cross-DSO CFI development. We're grateful for any and all contributions. Your support keeps HardenedBSD alive. Thank you for giving the HardenedBSD team the opportunity to serve you.

Looking forward into October, I'm hoping to fix the llvm toolchain issues. I need to put my administrative hat on and take care of financials. I plan to reach out to recent donors, asking if they want their name added to the donor's page. I plan to perform a rather major overhaul of our perimeter firewall towards the end of the month.

HardenedBSD August 2021 Status Report

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 2021 Donation Run

Over the past couple years, we've focused on growing our infrastructure, replacing old, inherited servers with newer refurbished ones. The community's selfless help has enabled this growth.

The vast majority of our hosting is free, and we're incredibly grateful for those who provide free or low-cost hosting. We do have one leased server that costs $155/month USD. Additionally, we pay $10/month USD for the Pushover.net notification service.

Due to replacing the aging hardware, and replacing the occasional dead part (mostly hard drives), we're sitting at around six months worth of funding.

We need $120/month USD to keep our non-free services online. With much gratitude for existing donations and humility, we are asking the community to provide recurring monthly donations totaling a minimum of $120/month USD.

Please note that The HardenedBSD Foundation is a tax-exempt charitable organization in the USA. Donations by those in the USA are eligible for tax deduction.

We accept donations in the following ways:

  1. PayPal: shawn.webb@hardenedbsd.org
  2. GitHub sponsors: https://github.com/sponsors/lattera
  3. Bitcoin: 1FmbSRvZK4yC1b6ajeZWSvYXV2nmvwdWQq
  4. Ethereum: 0x9Ea8E44736AC8Ed806ef57f7F174a14D93689775
  5. Amazon Smile: https://smile.amazon.com/ch/83-1287321

HardenedBSD May 2021 Status Report

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.


Subscribe to HardenedBSD RSS