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.

September was rather busy for me, so I didn't get the monthly status report out. So this status report covers both September and October 2024.

We received a donation of four devices from Protectli. These devices will help us research and develop a censorship- and surveillance-resistant mesh network. More information can be found here.

In the source tree:

1. Specifying a NULL environment variable in execve is now prohibited. This helps address ROP payloads that simply pass NULL as the envp.
2. The hardening.kmalloc_zero regression is fixed.
3. Use clang's C++ hardening integration. For more information, watch this presentation.

In ports:

1. FORTIFY_SOURCE has been disabled for the following ports:
   • net/samba416
   • devel/libgtop
   • sysutils/grub2-bhyve
   • devel/kronosnet
2. PIE was disabled for editors/libreoffice
3. devel/bsddialog build was fixed
4. PaX MPROTECT was disabled for www/node22
5. the devel/boost and related ports were fixed
6. base ranlib version detection was fixed
7. Default ports llvm version was bumped to 18
8. hardenedbsd/sourcezap was bumped to 1.2.1
9. hardenedbsd/portzap was bumped to 1.2.1

In other news, HardenedBSD 13-STABLE is in the process of being archived. Folks who want continued support for 13-STABLE are encouraged to create a free account on our self-hosted GitLab and submit patches. Otherwise, we encourage everyone to enjoy HardenedBSD 14-STABLE and 15-CURRENT.

We are grateful for those who contribute to the project--no matter the form in which the contribution comes. Continued advocacy, patch submissions, financial support, and other contributions are appreciated and needed.