This status report pertains to both July and August 2025. It has been a busy summer here in Colorado. We will conclude this report with a discussion on FreeBSD's 15.0 release engineering cycle and its impact on HardenedBSD.

The focus of the past few months has been addressing technical debt within the project.

In src:

1. The old hbsdcontrol (prior to the rewrite) was removed.
2. FreeBSD added the clang-scan-deps program to the build. Due to our use of LTO and CFI, we needed to add more files to the clang-scan-deps program's build.
3. Trusted Path Execution (TPE) is now integrated with mmap(PROT_EXEC) when a file descriptor is used to back the memory mapping.
4. TPE is now fully jail-aware.
5. First-time patch submitter Théo Bertin fixed hbsd-update's checking of certificates to take into account non-standard mount points.
6. The mac_do(4) module has been hardened to take into account the per-process flag that determines whether the process can change or be granted new privileges. Otherwise, a misconfiguration in mac_do(4)'s rules could result in a privilege escalation in an unprivileged chroot. We reported this issue upstream to FreeBSD, which does not seem to believe this to be an issue.
7. Addressed some vnode locking issues with TPE and SEGVGUARD.
8. 0x1eef helped address some issues with HardenedBSD's branding and recent changes by FreeBSD in the UEFI boot loader.

In ports:

1. net-p2p/heartwood and related have been bumped to 1.3.0.
2. Our patch to enable -frtivial-var-auto-init=zero by default in llvm/clang was forward ported to the devel/llvm20 and devel/llvm21 ports
3. _FORTIFY_SOURCE was disabled for security/fakeroot

We also addressed some cooling issues, enabling us to bring another server online. The server brought online is our test environment, currently configured to test Radicle. The Radicle project has made a lot of strides to be able to handle larger repos, but it still seems like it is a bit too early for HardenedBSD's use.

In September 2025, FreeBSD plans to create the stable/15 branch from their main development branch. HardenedBSD will need to follow suit, creating a new hardend/15-stable/master branch. We will need to bring online build infrastructure to build the installation media, pkgbase repo, and package repos. It will take me some time to perform that work, perhaps up to two months.

Depending on our continued cooling issues (which we partiailly mitigated this past month), we may be constrained as to how many branches we can support. As such, I am currently unsure how long we can support 14-stable. Once we get a handle on the new 15-stable branch and the dust settles, we will be able to make a better determination as to how long we'll support 14-stable.

In addition to the new stable branch, I plan to get back to working on the censorship- and surveillance-resistant mesh network. I'm hoping to better understand Reticulum and have an internal test Reticulum network deployed.

Introduction

As I mentioned in the April 2025 HardenedBSD Status Report, I had attended a small hackathon with a few FreeBSD developers. This hackathon was focused on providing basic support for optional userland components written in Rust. This is a status report for that work.

For those following along, we now have a feature branch (hardened/current/rust-in-base) for the Rust work.

Originally, I had intended to write a ubiquitous, generic "optional support for userland components written in other languages, starting with Rust." Alan, Warner, and I came up with something that looks different, specific to Rust.

Alan brought in a number of vendored dependencies. These dependencies live in the vendor/rust subdirectory of the src tree. He also created a src-specific Rust workspace. All optional installable userland components live in that Rust workspace.

We introduced a new BSD makefile, located at share/mk/bsd.rust.mk, that enables building a Rust application during buildworld. As of this writing, we only support building and installing Rust applications. Supporting library crates is planned (we would like to be able to build/install library crates that expose an FFI, like for C/C++ compatibility). Normal library crates build and install just fine. Support for cdylib Rust library crates specifically is what's missing, but is desired and planned.

We do NOT currently support Rust in the kernel. Kernel support requires more work that we deemed out-of-scope for this initial proof-of-concept/work-in-progress patchset. We also do NOT support building multiple programs in the same BSD Makefile (like with bsd.progs.mk), though that is also a desired feature.

The current patchset does support pkgbase.

Implementation

For Rust userland components, instead of including , you would include . share/mk/bsd.rust.mk is self-contained, doing much of the same work that share/mk/bsd.prog.mk performs.

The entire logic depends on a new src.conf knob: OPTIONAL_TOOLCHAINS. This variable should contain rust-cargo. If OPTIONAL_TOOLCHAINS does not contain "rust-cargo", the build of Rust components is skipped.

We rely on Cargo for building the application and its vendored dependencies. All crates that an application depends on lives in the vendor/rust subdirectory. When building, Cargo is instructed NOT to reach out to Internet-facing resources (the --offline flag is passed to cargo). Meaning, all crates that the to-be-built application depends on MUST be imported in to the `vendor/rust` subdirectory in the src tree.

env(1) is used to change directory to the to-be-built binary crate. It appears cargo can get confused when using the --path argument.

At buildworld time, cargo will build the vendored crates on which the component depends and the component itself. At installworld time, cargo will install the component to its rightful place.

Example Components

Several application crates have been imported into the hardened/current/rust-in-base branch. These are:

1. usr.bin/freebsd-geom-exporter
2. usr.bin/jail_exporter
3. usr.bin/nfs-exporter
4. usr.sbin/gstat

As of this writing, these example components (and the crates on which they depend) are not planned for upstreaming. They simply serve as good examples while we develop the underlying optional Rust-in-base support.

Next Steps

We still have a bunch of work left to do. The following list might not be complete, but it's comprised of the things I'd like to work on next.

1. Support for library crates as buildable/installable components. Specifically, support for cdylib library crates.
2. Support for building multiple Rust applications with a single Makefile (provide something akin to bsd.progs.mk).
3. Develop firmer guidlines on how to perform vendor imports of crates. This could already be a solved problem, given that FreeBSD already performs vendor imports of certain (non-Rust) components.
4. Support for installing manual pages, include files, and other auxiliary files.

Upstreaming

Once we feel confident in the overall approach, we will open a patch review in Phabricator. I believe the patchset, in its current state, is not well-suited for a formal review in Phabric. At the very least, the "next steps" items above need to be addressed.

March was a busy month for the project with regards to the infrastructure. We saw some commits to src and ports, but development was pretty quiet overall. On 12 March 2025, we drastically expanded power capacity in the server room, adding two new 20 amp circuits. The electrician also prepared for an eventual mini-split HVAC unit that we hope to requisition in the next year or two.

Due to the electrical work, we skipped performing package builds for March. We'll resume our regular package building schedule on 01 April 2025.

Years ago, we supported arm64 with HardenedBSD's hardened/current/master branch and provided regular builds and a package repo. We scaled down that support when I had switched employers. Back then, the infrastructure was hosted at my employer's mini-datacenter, whereas now it's hosted in my home. Now that we have the power capacity, I worked on powering on one of our two Cavium ThunderX1 servers. The NIC (an Intel NIC that uses the em(4) driver) seems not to be stable in this particular setup. Once we get stable networking, I plan to regain official support for HardenedBSD on arm64.

I worked with the Radicle team ( https://radicle.xyz/ ) to officially start research and development for larger code repositories. Currently, our src and ports repos are too large for Radicle to handle.

In the src tree:

1. 0x1eef wrote a periodic(8) script that applies a stricter set of permissions to certain files and directories. Please refer to /etc/mtree/BSD.hardened.dist for which files and directories are applicable.
2. The retain option in jemalloc is disabled by default (see malloc.conf(5)) for more information about this option. Disabling the retain option increases the entropy applied to the heap and can help mitigate Use-After-Free (UAF) vulnerabilities.
3. The IP ID randomization period was increased from 8192 to 32768. This increases the window of the randomized IP ID value, making it slightly more difficult for an attacker.

In the ports tree:

1. Register zeroing (ZEROREG) was enabled for net/wireshark.

I'd like to finish this status report with a call for donations. The last major hurdle for us is cooling. A mini-split heat pump HVAC unit is going to be crucial for us this summer as we scale up our infrastructure. We currently use a portable A/C unit, and that seems to be sufficient for now since outdoor temperatures are manageable. However, when summer hits and it's 110F outside, we may have to power off some servers to keep indoor temperatures steady. I have not received any estimates or quotes, but I suspect it will be between $5,000 and $7,000 USD. Donations by those in the US are eligible for tax deduction.

I plan to get us fully supported on LiberaPay over the next month or two. I've set up a profile here: https://liberapay.com/hardenedbsd-finances/. I still have some work to do in order to get us fully set up on LiberaPay. I will reply to this status report when the account's setup is complete.

In April, I plan to continue work on the BATMAN port. I'm hoping to get it to a buildable state. Once it's buildable, then we can separate the GPL code out into various ports entries.

I'm also coordinating with two other FreeBSD developers about optionally supporting different compiler toolchains, starting with Rust, for base userland components.

December was a delightfully relatively busy month for HardenedBSD. I started research on mitigating SROP due to a discussion with one of the Syd Linux developers. While I don't have an implementation just yet, I've started research on that.

I created a private fork of the HardenedBSD src tree meant for collaborating with Aymeric Wibo on completing the BATMAN-adv mesh networking support. The idea here is to use the private fork to first separate the GPL bits into ports entries. The bits of code that land in the public src tree will NOT be GPL.

Notable changes in the src tree:

1. There was a regression in how we apply ASLR to mmap(MAP_STACK) mappings. The delta was improperly computed but is now fixed.
2. Default to PIE on all architectures.
3. fusefs(4) is now compiled with -ftrivial-auto-var-init=zero.
4. syslogd will no longer accept remote connections by default. Please note that this could impact users' environments. Deployments that need to accept remote connections will need to be modified. Please reference commit 50ed55c154b79f41fadd4b77ede9c202b83435b5 for more information.
5. Enable use of -fzero-call-used-regs=used across (nearly) the entirety of base userland. The only component in base userland that has this feature disabled is in the bootloader.

Notable changes in the ports tree:

1. PaX PAGEEXEC is disabled for www/firefox.
2. Default LLVM version is bumped to 19, matching llvm in base.
3. _FORTIFY_SOURCE was disabled for:
   1. x11-wm/sway
   2. x11/swaybg
   3. x11/swaylock
4. net-p2p/heartwood-httpd was bumped.
5. Ports built with llvm-from-ports version 17, 18, and 19 will have -ftrivial-auto-var-init=zero enabled by default.
6. The build of devel/electron32 was fixed by using the default llvm version.
7. net-p2p/heartwood was bumped to 1.1.0.
8. Fix ranlib version detection.
9. security/libhijack version was bumped.
10. Apply -fzero-call-used-regs=all by default across the entire ports tree (new hardening option: ZEROREG).
11. Disable register zeroing for:
    1. archivers/libdeflate
    2. databases/mongodb80
    3. devel/highway
    4. devel/qt6-base
    5. devel/wasi-compiler-rt
    6. devel/wasi-libcxx
    7. editors/libreoffice
    8. graphics/libjxl
    9. graphics/openjph
    10. lang/go-devel (applies to golang universally)
    11. multimedia/svt-av1
    12. multimedia/vmaf
    13. security/libsodium
    14. www/node20
    15. www/node22
12. sysutils/vm-bhyve-hbsd version was bumped.

Please note that there likely is a lot of fallout to address regarding register zeroing in ports. The next few package builds for both 14-STABLE and 15-CURRENT will likely have a few packages missing. I plan to address those broken ports/packages as soon as I find out they're broken. Please be patient as we address the breakages.

I plan to apply updates across the entire HardenedBSD development infrastructure on Saturday, 04 Jan 2025. I will keep everyone informed as to when the maintenance period begins and ends. The package builds will commence immediately after the infrastructure is back online.

Happy New Years! I hope 2025 treats everyone well. I'm excited to see the mesh networking work progress. I believe we will see an every increasing need for the deployment of these types of networks.

The HardenedBSD Foundation and the community are immensly grateful for the contributions made in 2024. This project could not survive if not for the graceous contributions that come in all their forms: monetary, patch submissions, advocacy, documentation, and otherwise. We look forward to a bright and productive 2025.