Optional Rust-in-FreeBSD Support Status Report

[Shawn Webb]

Introduction
============

As I mentioned in the April 2025 HardenedBSD status report[1], 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 for the Rust work. That
can be found at [2].

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[3], 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 <bsd.prog.mk>, you would
include <bsd.rust.mk>. share/mk/bsd.rust.mk is self-contained, doing much of the
same work that share/mk/bsd.prog.mk.

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.

[1]: https://hardenedbsd.org/article/shawn-webb/2025-05-01/hardenedbsd-april-2025-status-report
[2]: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened/current/rust-in-base
[3]: https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/blob/hardened/current/rust-in-base/share/mk/bsd.rust.mk

Thanks,

--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

Signal Username: shawn_webb.74
Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50
https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc