FreeBSD The Power to Serve

FreeBSD Status Report Second Quarter 2023

Here is the second 2023 status report, with 37 entries.

As you might notice, we have several more reports than last quarter. This is a great news and shows how much the FreeBSD community is active and always working on providing high quality software.

In particular, please note that Summer has started and do not miss the amazing projects shared by our Google Summer of Code students.

Have a nice read.

Lorenzo Salvadore, on behalf of the Status Team.

FreeBSD Team Reports

Entries from the various official and semi-official teams, as found in the Administration Page.

FreeBSD Core Team

Contact: FreeBSD Core Team <>

The FreeBSD Core Team is the governing body of FreeBSD.

DevSummit 202305

The Core Team has presented the status update at the FreeBSD Developer Summit, 17th–18th May. Slides are available at

FreeBSD 14

The Core Team is working with other teams to ensure that FreeBSD 14.0-RELEASE will be of the highest quality.

The Core Team has no objection to mark riscv64sf (64-bit RISC-V soft-float) as unsupported in 14.

Meetings with The FreeBSD Foundation

The Core Team and The FreeBSD Foundation continue to meet regularly to discuss the next steps to take for the management, development, and future of FreeBSD. The Core Team had two meetings with the Board of Directors of, and employees of, the Foundation. They discussed how the Foundation can help the Core Team and the Project in general.

Matrix IM solution

One of the major items in the Core Team updates in DevSummit 202305 was proposing a new project communication solution.

There is currently a testing instance at setup by clusteradm. All developers can access the instance with their kerberos credentials, and some public rooms can be joined through Matrix’s federation feature. Please note this instance is for testing and evaluating so no backup or availability is guaranteed.

The Core Team is still discussing the scope and administration of this service, and collecting feedback from the community.

Code of Conduct Committee

Code of Conduct Committee (conduct@) is managed by the Core Team now.

Commit bits

Core approved the src commit bit for Christos Margiolis (christos@).

FreeBSD Foundation

Contact: Deb Goodkin <>

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Donations from individuals and corporations are used to fund and manage software development projects, conferences, and developer summits. We also provide travel grants to FreeBSD contributors, purchase and support hardware to improve and maintain FreeBSD infrastructure, and provide resources to improve security, quality assurance, and release engineering efforts. We publish marketing material to promote, educate, and advocate for the FreeBSD Project, facilitate collaboration between commercial vendors and FreeBSD developers, and finally, represent the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity.

Happy 30th birthday, FreeBSD!

For more than 23 years, we have proudly backed this remarkable operating system and its vibrant community, and we eagerly anticipate supporting them for many more years. In this update, we will outline our contributions to FreeBSD across multiple domains. We will touch upon project development initiatives, some of which have detailed reports of their own. Additionally, we will showcase our advocacy for FreeBSD, our efforts to foster community engagement, and our expansion of partnership endeavors. Lastly, we will delve into our ongoing work to secure increased funding, enabling us to allocate additional resources to address any gaps within the Project.


During this quarter, we made significant progress in engaging with commercial FreeBSD users. To enhance our partnerships with existing and potential commercial users, we hired Greg Wallace as the Director of Partnerships and Research. His primary objective is to expand our collaborations with commercial users. Since assuming this position, Greg has hit the ground running, meeting with numerous companies in just one quarter. These interactions have provided valuable insights into how FreeBSD is being utilized, the challenges faced by users, and areas where the Project can improve. By understanding these aspects, we can make informed decisions on where to allocate our funding and recognize FreeBSD’s unique strengths. Additionally, the role involves conducting research to identify target markets, explore new opportunities for FreeBSD, and ensure our voice is heard in relevant discussions. For more details on Greg’s objectives and accomplishments, you can refer to his status update below.

The Foundation extends its heartfelt gratitude to everyone who made financial contributions to support our work. Besides many individual contributions, we were pleased to receive larger donations from NetApp and Blackberry. In addition, we received FreeBSD Developer Summit sponsorships from Tarsnap, iXsystems, and LPI. These sponsorships greatly assist in offsetting our expenses and enable us to offer affordable registration fees to attendees.

This year our budget is around $2,230,000, which includes increased spending toward FreeBSD advocacy and software development. More than half of our budget is allocated toward work directly related to improving FreeBSD and keeping it secure.

By having a dedicated individual focused on partnerships, we can effectively emphasize the significance of investing in our efforts and underscore the long-term viability of the Project to companies.

Your support plays a crucial role in our mission, and we deeply appreciate your commitment to the FreeBSD community. Please consider making a donation toward our 2023 fundraising campaign!

For more prominent commercial donors we have the FreeBSD Foundation Partnership Program, which was established in 2017.

Partnership Program

Hello FreeBSD community. My name is Greg Wallace. I joined the Foundation as Director of Partnerships and Research in early April. This blog introduced me and the role. For Partnerships, I am focused on building connections with companies that use FreeBSD. I have met with several companies to learn about how they use FreeBSD. Some of these meetings have generated discussions about potential partnership. I continue to find out about interesting companies using FreeBSD and I am reaching out to them.

My objective is to get in touch with every company building with and using FreeBSD to listen to their stories. If this is you and we have not yet connected, please schedule a call on my calendar.

Some other partnership-related activities this quarter:

  • I created these slides about how partnering with the Foundation helps advance FreeBSD. If you have ideas for how I can improve these slides, or would like me to present them to your organization, please send me an email, or schedule a call. And please feel free to share the presentation liberally, in whole or in part.

  • I worked with my Foundation colleagues to create a number of industry-specific use case slides for a presentation to an industry analyst.

  • I am also pursuing grant opportunities with bodies including:

    • NSF Secure and Trustworthy Cyberspace (SaTC)

    • Sovereign Tech Fund

    • NGI.

In terms of research, my broad aim is to make sure that all of the expertise in this community is reflected in the global conversations on computing performance, security, and energy efficiency. As a community, we have much to bring to this work.

So far, I have been tracking and plugging into the following threads:

If you have research ideas or are interested in working together in this area, please send me an email, or schedule a call.

OS Improvements

During the second quarter of 2023, 339 src, 155 ports, and 20 doc tree commits identified The FreeBSD Foundation as a sponsor. Some of this and other Foundation-sponsored work is described in separate report entries:

Here is a sampling of other Foundation-sponsored work:

  • Bug fixes for fsck_ffs(8)

  • Bug fixes for killpg(2)

  • Improvements to hwpmc

  • Improvements to vmm

  • Port fixes and workarounds for LLVM 16 and OpenSSL 3.0

  • Port kinst to RISC-V and related DTrace work

  • Update of libfido2 to version 1.9.0

  • Various LinuxKPI 802.11 improvements

  • Various RISC-V improvements

  • Vendor import and update of tcpdump from version 4.9.3 to version 4.99.4.

The status of current and past Foundation-contracted work can be viewed on the Foundation Projects page.

Members of the Foundation’s technology team presented at the Developer Summit held in Ottawa, Canada from May 17-18. This included hosting the GSoC, FreeBSD Foundation Technical Review, and Workflow working group sessions. Pierre Pronchery spoke about driver harmony between the BSDs and En-Wei Wu discussed wtap work completed under contract with the Foundation.

Continuous Integration and Quality Assurance

The Foundation provides a full-time staff member and funds projects to improve continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. You can read more about CI work in a dedicated report entry.


Much of our effort is dedicated to the FreeBSD Project advocacy. This may involve highlighting interesting FreeBSD work, producing literature and video tutorials, attending events, or giving presentations. The goal of the literature we produce is to teach people FreeBSD basics and help make their path to adoption or contribution easier. Other than attending and presenting at events, we encourage and help community members run their own FreeBSD events, give presentations, or staff FreeBSD tables.

The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, working together on projects, and facilitating collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. We are grateful to be back to attending events mostly in person. In addition to attending and planning events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD.

Check out some of the advocacy and education work we did:

We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues at

You can find out more about events we attended and upcoming events at

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise.

Go to to find more about how we support FreeBSD and how we can help you!

FreeBSD Release Engineering Team

Contact: FreeBSD Release Engineering Team <>

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things.

During the second quarter of 2023, the Team continued work on 13.2-RELEASE. The 13.2 cycle had closely followed the set schedule, with the addition of three additional RC builds at the end, and the final RELEASE build and announcement in mid-April.

In coordination with various teams within the Project management, the FreeBSD Release Engineering Team reconsidered the original schedule for the upcoming 14.0-RELEASE, primarily due to work that was in progress. The updated schedule was discussed and adjusted slightly to account for some concerns, and ultimately published on the FreeBSD Project website. The new schedule targets 14.0-RELEASE for October, 2023.

The Team continued providing weekly development snapshot builds for the main, stable/13, and stable/12 branches. Note, there will no longer be snapshot builds against stable/12 moving forward.

Sponsor: Tarsnap
Sponsor: The FreeBSD Foundation

Cluster Administration Team

Contact: Cluster Administration Team <>

FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronise its distributed work and communications.

In this quarter, the team has worked on the following:

  • Regular support for user accounts.

  • Regular disk and parts support (and replacement) for all physical hosts and mirrors.

  • Enable mirroring of and in the FreeBSD project-managed mirrors.

  • Cluster refresh, upgrading all hosts and jails to the most recent versions of 14-CURRENT, 13-STABLE, and 12-STABLE.

Work in progress

  • Large-scale network upgrade at our primary site.

    • New Juniper switches arrived at our primary site to replace the former ones. We thank Juniper for the donation.

  • Replace old servers in our primary site and a few mirrors.

    • Besides the broken CI servers, we have a few old servers with broken disks and faulty PSUs. This task is in conjunction with The FreeBSD Foundation and donors/sponsors.

  • Install new CI (Continuous Integration) machines repurposed from the package builders.

  • Review the backup configuration of the services running in the FreeBSD cluster.

FreeBSD Official Mirrors Overview

Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Taiwan, United Kingdom (full mirror site), United States of America — California, New Jersey (primary site), and Washington.

The hardware and network connection have been generously provided by:

The Frankfurt single server mirror is the primary Europe mirror in bandwidth and usage.

We are still looking for an additional full mirror site (five servers) in Europe to replace old servers in the United Kingdom full mirror site.

We see a good pattern in having single mirrors in Internet Exchange Points worldwide (Australia, Brazil, and South Africa); if you know or work for some of them that could sponsor a single mirror server, please get in touch. United States (West Coast) and Europe (anywhere) are preferable places.

See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site.

Continuous Integration

Contact: Jenkins Admin <>
Contact: Li-Wen Hsu <>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

In the second quarter of 2023, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD.

Important completed tasks:

Work in progress tasks:

  • Designing and implementing pre-commit CI building and testing (to support the workflow working group)

  • Designing and implementing use of CI cluster to build release artifacts as release engineering does

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Organizing the scripts in freebsd-ci repository to prepare for merging to src repository

  • Improving the hardware test lab and adding more hardware for testing

  • Merge

  • Merge

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Planning to run ztest tests

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort!

Sponsor: The FreeBSD Foundation

Ports Collection

Contact: René Ladan <>
Contact: FreeBSD Ports Management Team <>

The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. elow is what happened in this quarter.

Currently there are just over 34,400 ports in the Ports Tree. There are currently 3,019 open ports PRs of which 746 are unassigned. This quarter saw 10,439 commits on the main branch by 151 committers and 745 commits on the 2023Q2 branch by 55 committers. Compared to the previous quarter, this means a slight increase in the number of ports, a tiny decrease in the number of open PRs, and a fair increase in the number of ports commits.

During this quarter, we welcomed back Tom Judge (tj@) and said goodbye to Steve Wills (swills@). Steve was also on portmgr. As part of the portmgr lurker program, we welcomed Ronald Klop (ronald@), Renato Botelho (garga@), and Matthias Andree (mandree@).

Portmgr has resumed work on introducing sub-packages into the Tree, but various things still need to be fleshed out.

On the software side, pkg was updated to 1.19.2, Firefox to 114.0.2, Chromium to 114.0.5735.198, and KDE Gear to 23.04.2. During this quarter, antoine@ ran 23 exp-runs to test package updates, bump CPU_MAXSIZE to 1024, fix armv7 failures for devel/cmake-core and add --auto-features=enabled to USES=meson Lastly, the Ports Tree was updated to support LLVM 16 and OpenSSL 3 in FreeBSD-CURRENT.


Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.


Contact: Brooks Davis <>
Contact: Ed Maste <>
Contact: Li-Wen Hsu <>

Cirrus-CI is a hosted continuous integration service that supports open source projects with CI services on Linux, Windows, macOS, and FreeBSD. It complements our own Jenkins CI infrastructure by supporting other use cases, including testing GitHub pull requests and FreeBSD forks. We added Cirrus-CI configuration to the FreeBSD src tree in 2019 and to doc in 2020. A number of additional FreeBSD projects hosted on GitHub (such as drm-kmod, kyua, pkg, and poudriere) also make use of Cirrus-CI.

Cirrus-CI configs received ongoing maintenance updates (moving to the most recent FreeBSD release images). In the src tree we have added some additional checks. These ensure that generated files are updated when needed (make sysent and make makeman) and check for missing directories. We have added jobs that build using the Clang/LLVM 16 toolchain package, mirroring the Clang version now in the base system. The GCC job is now run on the GitHub mirror by default, for all commits.

Sponsor: DARPA
Sponsor: The FreeBSD Foundation

BATMAN support in the FreeBSD kernel

Contact: Aymeric Wibo <>

BATMAN (Better Approach to Mobile Ad-hoc Networking), as developed and used by the Freifunk project, is a routing protocol for (primarily wireless) multi-hop ad-hoc networks. Freifunk is a German initiative to build an open Wi-Fi network at city-scale, based on the principles of net-neutrality. BATMAN’s motive is to be a completely decentralized protocol; no one node in the network knows or has to care about the topology of the whole network.

Support for this protocol is provided by the batman-adv kernel module on Linux, and this project aims to bring that to FreeBSD. This includes the kernel module itself, but also userland networking libraries and tools necessary to create BATMAN networks.

Currently, creating interfaces and interacting with them works (with both Linux and FreeBSD userspaces), and packet transmission (kind of) works, although it is incomplete as of yet. Support for batadv interfaces has been added to ifconfig(8) too.

Mentor: Mahdi Mokhtari

Sponsor: The Google Summer of Code '23 program

FreeBSD support on LinuxBoot

Contact: Warner Losh <>

LinuxBoot is an effort to create a clean, robust, auditable and repeatable boot firmware. What originally started as a specific project at Google has grown to encompass any boot environment that uses Linux to launch the final operating system. Many platforms now support this environment, and in some cases it is the only available boot environment. In addition, some embedded boxes have a LinuxBoot environment hard-coded that is quite hard to change, and being able to reboot into FreeBSD is desirable.

The old Sony PlayStation 3 port used a boot loader called 'kboot' to boot the FreeBSD port from its Linux kernel (all predating the LinuxBoot project). That code has been greatly expanded, made generic with easily replaceable per-architecture plug ins. The normal FreeBSD /boot/loader is built as a Linux binary that reads in the FreeBSD kernel, modules and tunables. It places them into memory as if it were running in a pre-boot environment, then loads that image into the Linux kernel with kexec_load(2) and does a special reboot to that image. For UEFI-enabled systems, it passes the UEFI memory table and pointer to UEFI runtime services to the new kernel.

It supports loading files from the host’s filesystem, from any loader(8)-supported filesystem on the host’s block devices (including pools that span multiple devices), from ram disk images and from files downloaded over the network. Any mix of these is available. So, for example, configuration overrides can be loaded from the host’s filesystem whilst the kernel loads from dedicated storage (say NVME) or a ram disk image. It supports a host console running over stdin/stdout. It supports explicit locations such as /dev/nvme0ns1:/boot/loader/gerbil.conf for where to load filesystems from. It supports ZFS boot environments, including the boot-once feature.

Additional details about kboot, what it supports and some general background can be found in Warner’s BSDcan talk (slides linked above).

FreeBSD/aarch64 now can boot from Linux in a LinuxBoot environment, with support and functionality comparable to loader.efi(8). Memory layout passed in for GICv3 workarounds. Need patch for aarch64 kernel for the GICv3 workaround (

FreeBSD/amd64 support is in progress and is maybe 80% done. The amd64 boot environment places more requirements on the boot loader to provide data for the kernel than aarch64, due to amd64 being an older port. All sources for data in the BIOS environment had to be provided by the boot loader since the kernel had no access to them from long mode. While UEFI and ACPI provide ways for the kernel to get this data, much of the data must still be provided by the boot loader. The kernel panics during initialization since all these prerequisites have not been discovered and implemented.

PowerPC builds, but nothing more of its state is known. Attempts to acquire a suitable Playstation 3 proved to be too time consuming for the author.

Help Needed

  1. loader.kboot(8) needs to be written. It should document how to use loader.kboot, how to create images, and the use cases that work today.

  2. Finish amd64 support.

  3. The current elf arch-specific metadata code is copied from efi. Unifying the kboot and efi copies is needed. While they are mostly the same, sharing is complicated by remaining compile-time differences. In addition, the build infrastructure makes sharing awkward.

  4. It would be nice to add riscv64 support.

  5. PowerPC testing (it has been untested since the refactoring started).

  6. Creating a script to repackage EDK-II image (say, from QEMU) as a linux-boot image with a Linux kernel built on FreeBSD for CI testing.

  7. Testing it from the coreboot LinuxBoot.

Sponsored by: Netflix, Inc

LLDB Kernel Module Improvement

Contact: Sheng-Yi Hong <>

FreeBSD project uses LLVM as its toolchain. The LLVM project has bundled with a debugger called LLDB. In LLDB, the userspace debugging facilities has been well implemented. However, in the kernel space, there are still some works have to be done. One of the work is the kernel module debug facility for LLDB - that is, parse the loaded module data provided by the kernel core dump and loading the module objects. The goal is to implement such plugin for LLDB, and this is an ongoing GSoC Project for now.

Project Codebase is the whole code of my work.

Currently, this is still a work in progress and I am still debugging on it.

Sponsor: The Google Summer of Code '23 program


Changes affecting the base system and programs in it.

OpenSSL 3 in base

Contact: Pierre Pronchery <>

Pierre has been tasked with importing OpenSSL 3 into the base system.

OpenSSL is a library for general-purpose cryptography and secure communication. It provides an open source implementation of the SSL and TLS network protocols, which are widely used in applications such as e-mail, instant messaging, Voice over IP (VoIP), or more prominently the global Web (aka HTTPS). Assuming that the Apache and nginx web servers use OpenSSL, their combined market share for web traffic exceeds 50%, cementing the leadership and critical importance of OpenSSL as part of the infrastructure of the Internet.

Since its initial release in August 2016, the 1.1 branch of OpenSSL has been adopted by most Linux and BSD systems, while remaining supported by the upstream maintainers through an LTS (long term support) policy. However, official support is planned to end in the middle of September this year, and it became urgent and necessary to consider adopting its successor for LTS, the 3.0 branch.

OpenSSL has largely outgrown its ancestor SSLeay, now shipping over half a million single lines of code (SLOC) split in over two thousand files. Perhaps as a consequence, its build system is relatively complex and normally requires Perl, which was removed from base more than twenty years ago for FreeBSD 5.0-RELEASE. Thankfully however, it was possible to import and setup OpenSSL 3.0.9 the FreeBSD way, and it is now part of the base system as planned for FreeBSD 14.0-RELEASE.

To describe OpenSSL 3 as a major release is an understatement. First, its problematic licensing model has finally been solved, with a complete switch to the Apache License 2.0. Then, OpenSSL 3 introduces the concept of provider modules. While obsolete cryptographical algorithms have been isolated to a legacy module, it is also possible to restrict the implementation to the standards part of FIPS with the fips module. The latter can then benefit from a dedicated certification process, and be validated officially (like the 3.0.8 release at the time of writing).

Moreover, the updated library comes with a version bump, as applications using OpenSSL 1.1 need to be recompiled to use 3.0. Many API functions have been deprecated and replaced with newer, more generic alternatives, however it is still possible to explicitly request older APIs and have OpenSSL 3 expose them accordingly. This possibility has been leveraged in FreeBSD to help with the transition, where a number of libraries and applications have simply been configured to request the OpenSSL 1.1 API. These components will be updated progressively over time in order to consume OpenSSL 3’s native API instead.

While there is a known performance impact associated with the update when consuming small input block sizes, it was found to be marginal when working with blocks of 1 KB and above. Another challenge lies with the FIPS provider module, which currently requires some manual steps in order to have it working. We are currently looking for a solution to ship FreeBSD with a functional FIPS provider by default.

Sponsor: The FreeBSD Foundation

Linux compatibility layer update

Contact: Dmitry Chagin <>

The goal of this project is to improve FreeBSD’s ability to execute unmodified linux(4) binaries.

As of cbbac5609115, preserving an fpu xsave state across signal delivery on amd64 is implemented. That makes it possible to run modern golang with preemptive scheduler on.

The new facility to specify an alternate ABI root path was added to namei(9). Previously, to dynamically reroot lookups, every linux(4) syscall where path names translation is needed required a bit of ugly code and used kern_alternate_path() which does not properly resolve symlinks with leading / in the target. For now a non-native ABI (i.e., linux(4)) uses one call to pwd_altroot() during exec-time into that ABI to specify its root directory (e.g., /compat/ubuntu) and forget about path names translation. That makes possible chroot into the Ubuntu compat without having to fix such symlinks by hand.

In total, over 10 bugs were fixed; glibc-2.37 tests suite reports less than 70 failed tests.

Service Jails — automatic jailing of rc.d services

Contact: Alexander Leidinger <>

Service jails extend the rc(8) system to allow automatic jailing of rc.d services. A service jail inherits the filesystem of the parent host or jail, but uses all other limits of the jail (process visibility, restricted network access, filesystem mounting permissions, sysvipc, …​) by default. Additional configuration allows inheritance of the IPs of the parent, sysvipc, memory page locking, and use of the bhyve virtual machine monitor (vmm(4)).

If you want to put e.g. local_unbound into a service jail and allow IPv4 and IPv6 access, simply change rc.conf(5) to have:


While this does not have the same security benefits of a manual jail setup with a separate filesystem and IP/VNET, it is much easier to setup, while providing some of the security benefits of a jail like hiding other processes of the same user.

The patches in the links are a rewrite of what I presented in 2019. The main difference is that an ENV variable is used to do more rational tracking and as such, requires a change to service(8).

My intent is to commit D40369 before the branch of stable/14. I will not commit D40370 or D40371 before 14.0 is released and both will benefit from more eyes.

Security Sandboxing Using ktrace(1)

Contact: Jake Freeland <>

Capsicumization With ktrace(1)

This report introduces an extension to ktrace(1) that logs capability violations for programs that have not been Capsicumized.

The first logical step in Capsicumization is determining where your program is raising capability violations. You could approach this issue by looking through the source and removing Capsicum-incompatible code, but this can be tedious and requires the developer to be familiar with everything that is not allowed in capability mode.

An alternative to finding violations manually is to use ktrace(1). The ktrace(1) utility logs kernel activity for a specified process. Capsicum violations occur inside of the kernel, so ktrace(1) can record and return extra information about your program’s violations with the -t p option.

Programs traditionally need to be put into capability mode before they will report violations. When a restricted system call is entered, it will fail and return with ECAPMODE: Not permitted in capability mode. If the developer is doing error checking, then it is likely that their program will terminate with that error. This behavior made violation tracing inconvenient because ktrace(1) would only report the first capability violation, and then the program would terminate.

Luckily, a new extension to ktrace(1) can record violations when a program is NOT in capability mode. This means that any developer can run capability violation tracing on their program with no modification to see where it is raising violations. Since the program is never actually put into capability mode, it will still acquire resources and execute normally.

Violation Tracing Examples

The cap_violate program, shown below, attempts to raise every type of violation that ktrace(1) can capture:

# ktrace -t p ./cap_violate
# kdump
1603 ktrace   CAP   system call not allowed: execve
1603 foo      CAP   system call not allowed: open
1603 foo      CAP   system call not allowed: open
1603 foo      CAP   system call not allowed: open
1603 foo      CAP   system call not allowed: open
1603 foo      CAP   system call not allowed: readlink
1603 foo      CAP   system call not allowed: open
1603 foo      CAP   cpuset_setaffinity: restricted cpuset operation
1603 foo      CAP   openat: restricted VFS lookup: AT_FDCWD
1603 foo      CAP   openat: restricted VFS lookup: /
1603 foo      CAP   system call not allowed: bind
1603 foo      CAP   sendto: restricted address lookup: struct sockaddr { AF_INET, }
1603 foo      CAP   socket: protocol not allowed: IPPROTO_ICMP
1603 foo      CAP   kill: signal delivery not allowed: SIGCONT
1603 foo      CAP   system call not allowed: chdir
1603 foo      CAP   system call not allowed: fcntl, cmd: F_KINFO
1603 foo      CAP   operation requires CAP_WRITE, descriptor holds CAP_READ
1603 foo      CAP   attempt to increase capabilities from CAP_READ to CAP_READ,CAP_WRITE

The first 7 system call not allowed entries did not explicitly originate from the cap_violate program code. Instead, they were raised by FreeBSD’s C runtime libraries. This becomes apparent when you trace namei translations alongside capability violations using the -t np option:

# ktrace -t np ./cap_violate
# kdump
1632 ktrace   CAP   system call not allowed: execve
1632 ktrace   NAMI  "./cap_violate"
1632 ktrace   NAMI  "/libexec/"
1632 foo      CAP   system call not allowed: open
1632 foo      NAMI  "/etc/libmap.conf"
1632 foo      CAP   system call not allowed: open
1632 foo      NAMI  "/usr/local/etc/libmap.d"
1632 foo      CAP   system call not allowed: open
1632 foo      NAMI  "/var/run/"
1632 foo      CAP   system call not allowed: open
1632 foo      NAMI  "/lib/"
1632 foo      CAP   system call not allowed: readlink
1632 foo      NAMI  "/etc/malloc.conf"
1632 foo      CAP   system call not allowed: open
1632 foo      NAMI  "/dev/pvclock"
1632 foo      CAP   cpuset_setaffinity: restricted cpuset operation
1632 foo      NAMI  "ktrace.out"
1632 foo      CAP   openat: restricted VFS lookup: AT_FDCWD
1632 foo      NAMI  "/"
1632 foo      CAP   openat: restricted VFS lookup: /
1632 foo      CAP   system call not allowed: bind
1632 foo      CAP   sendto: restricted address lookup: struct sockaddr { AF_INET, }
1632 foo      CAP   socket: protocol not allowed: IPPROTO_ICMP
1632 foo      CAP   kill: signal delivery not allowed: SIGCONT
1632 foo      CAP   system call not allowed: chdir
1632 foo      NAMI  "."
1632 foo      CAP   system call not allowed: fcntl, cmd: F_KINFO
1632 foo      CAP   operation requires CAP_WRITE, descriptor holds CAP_READ
1632 foo      CAP   attempt to increase capabilities from CAP_READ to CAP_READ,CAP_WRITE

In practice, capability mode is always entered following the initialization of the C runtime libraries, so a program would never trigger those first 7 violations. We are only seeing them because ktrace(1) starts recording violations before the program starts.

This demonstration makes it clear that violation tracing is not always perfect. It is a helpful guide for detecting restricted system calls, but may not always parody your program’s actual behavior in capability mode. In capability mode, violations are equivalent to errors; they are an indication to stop execution. Violation tracing is ignoring this suggestion and continuing execution anyway, so invalid violations may be reported.

The next example traces violations from the unzip(1) utility (pre-Capsicumization):

# ktrace -t np unzip
creating: bar/
extracting: bar/bar.txt
creating: baz/
extracting: baz/baz.txt
# kdump
1926 ktrace   CAP   system call not allowed: execve
1926 ktrace   NAMI  "/usr/bin/unzip"
1926 ktrace   NAMI  "/libexec/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/etc/libmap.conf"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/usr/local/etc/libmap.d"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/var/run/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/usr/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/usr/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/usr/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/usr/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: readlink
1926 unzip    NAMI  "/etc/malloc.conf"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/dev/pvclock"
1926 unzip    NAMI  ""
1926 unzip    CAP   openat: restricted VFS lookup: AT_FDCWD
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/etc/localtime"
1926 unzip    NAMI  "bar"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    CAP   system call not allowed: mkdir
1926 unzip    NAMI  "bar"
1926 unzip    NAMI  "bar"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "bar/bar.txt"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "bar/bar.txt"
1926 unzip    CAP   openat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "baz"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    CAP   system call not allowed: mkdir
1926 unzip    NAMI  "baz"
1926 unzip    NAMI  "baz"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "baz/baz.txt"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "baz/baz.txt"
1926 unzip    CAP   openat: restricted VFS lookup: AT_FDCWD

The violation tracing output for unzip(1) is more akin to what a developer would see when tracing their own program for the first time. Most programs link against libraries. In this case, unzip(1) is linking against libarchive(3), which is reflected here:

1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/lib/"
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/usr/lib/"

The violations for unzip(1) can be found below the C runtime violations:

1926 unzip    NAMI  ""
1926 unzip    CAP   openat: restricted VFS lookup: AT_FDCWD
1926 unzip    CAP   system call not allowed: open
1926 unzip    NAMI  "/etc/localtime"
1926 unzip    NAMI  "bar"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    CAP   system call not allowed: mkdir
1926 unzip    NAMI  "bar"
1926 unzip    NAMI  "bar"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "bar/bar.txt"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "bar/bar.txt"
1926 unzip    CAP   openat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "baz"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    CAP   system call not allowed: mkdir
1926 unzip    NAMI  "baz"
1926 unzip    NAMI  "baz"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "baz/baz.txt"
1926 unzip    CAP   fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip    NAMI  "baz/baz.txt"
1926 unzip    CAP   openat: restricted VFS lookup: AT_FDCWD

In this instance, unzip(1) is recreating the file structure contained in the zip archive. Violations are being raised because the AT_FDCWD value cannot be used in capability mode. The bulk of these violations can be fixed by opening AT_FDCWD (the current directory) before entering capability mode and passing that descriptor into openat(2), fstatat(2), and mkdirat(2) as a relative reference.

Violation tracing may not automatically Capsicumize programs, but it is another tool in the developer’s toolbox. It only takes a few seconds to run a program under ktrace(1) and the result is almost always a decent starting point for sandboxing your program using Capsicum.

Sponsor: FreeBSD Foundation

NVMe over Fabrics

Contact: John Baldwin <>

NVMe over Fabrics enables communication with a storage device using the NVMe protocol over a network fabric. This is similar to using iSCSI to export a storage device over a network using SCSI commands.

NVMe over Fabrics currently defines network transports for Fibre Channel, RDMA, and TCP.

The work in the nvmf2 branch includes a userland library (lib/libnvmf) which contains an abstraction for transports and an implementation of a TCP transport. It also includes changes to nvmecontrol(8) to add 'discover', 'connect', and 'disconnect' commands to manage connections to a remote controller.

The branch also contains an in-kernel Fabrics implementation. nvmf_transport.ko contains a transport abstraction that sits in between the nvmf host (initiator in SCSI terms) and the individual transports. nvmf_tcp.ko contains an implementation of the TCP transport layer. nvmf.ko contains an NVMe over Fabrics host (initiator) which connects to a remote controller and exports remote namespaces as disk devices. Similar to the nvme(4) driver for NVMe over PCI-express, namespaces are exported via /dev/nvmeXnsY devices which only support simple operations, but are also exported as ndaX disk devices via CAM. Unlike nvme(4), nvmf(4) does not support the nvd(4) disk driver. nvmecontrol(8) can be used with remote namespaces and remote controllers, for example to fetch log pages, display identify info, etc.

Note that nvmf(4) is currently a bit simple and some error cases are still a TODO. If an error occurs, the queues (and backing network connections) are dropped, but the devices stay around, with I/O requests paused. nvmecontrol reconnect can be used to connect a new set of network connections to resume operation. Unlike iSCSI which uses a persistent daemon (iscsid(8)) to reconnect after an error, reconnections must be made manually.

The current code is very new and likely not robust. It is certainly not ready for production use. Experienced users who do not mind all their data vanishing in a puff of smoke after a kernel panic, and who have an interest in NVMe over Fabrics, can start testing it at their own risk.

The next main task is to implement a Fabrics controller (target in SCSI language). Probably a simple one in userland first followed by a "real" one that offloads the data handling to the kernel but is somewhat integrated with ctld(8) so that individual disk devices can be exported via iSCSI or NVMe, or via both using a single config file and daemon to manage all of that. This may require a fair bit of refactoring in ctld to make it less iSCSI-specific. Working on the controller side will also validate some of the currently under-tested API design decisions in the transport-independent layer. I think it probably does not make sense to merge any of the NVMe over Fabrics changes into the tree until after this step.

Sponsored by: Chelsio Communications


Updates to kernel subsystems/features, driver support, filesystems, and more.

Boot Performance Improvements

Contact: Colin Percival <>

Colin is coordinating efforts to speed up the FreeBSD boot process.

Recent efforts have moved from EC2 to the Firecracker virtual machine manager, which provides a very minimalist environment; stripping the boot process down to the bare minimum makes it easier to identify the remaining time and determine whether it can be optimized further.

With some experimental patches to both FreeBSD and Firecracker, it is now possible to boot a FreeBSD kernel in under 20 ms.

Some of the recent improvements were discussed in Colin’s Porting FreeBSD to Firecracker session at BSDCan.

This work is supported by his FreeBSD/EC2 Patreon.

CI Test Harness For Bootloader

Contact: Sudhanshu Mohan Kashyap <>

FreeBSD supports multiple architectures, file systems, and disk-partitioning schemes. I am trying to write a Lua script which would allow for testing boot loader of all the architecture combinations supported in the first and second-tier support, and provide a report on any broken combinations and expected functionality. If time permits, further exploration could be done to integrate the script into the existing build infrastructure (either Jenkins or GitHub Actions) to generate a comprehensive summary of the test results.

Currently any changes made by developer might inhibit the ability of the operating system to boot in some specific environment. These scripts provide assurance that changes do not cause regressions for the tested environments. The scripts are designed to be efficient and much less expensive than a full make universe required today. These attributes allow developers to routinely use the script, and allow integration into the CI pipelines without undue cost.

Currently script related work seems to be on track, but certainly ahead I will need to find all different kinds of QEMU recipes to test different environments. If anyone has any kind of working QEMU recipe for currently released versions of FreeBSD, feel free to send to me via mail at .

Sponsor: The Google Summer of Code '23 program

Physical memory compaction for the FreeBSD kernel

Contact: Bojan Novković <>

Most modern CPU architectures offer performance boosts by supporting pages that are larger than the standard page size. Unfortunately, allocating such pages can fail due to a high degree of physical memory fragmentation. This work implements physical memory compaction as a means of actively reducing fragmentation in running systems. This work is part of an ongoing Google Summer of Code project, the goal of which is to add various physical memory anti-fragmentation measures to the virtual memory subsystem.

Differential D40575 implements a well-known metric used for quantifying the degree of physical memory fragmentation. Differential D40772 implements physical memory compaction and adds a daemon that monitors the system and performs compaction when needed.

Planned future work includes designing an appropriate benchmarking suite, running tests, and tweaking the code using feedback from reviews and test results. This is still a work in progress, so any testing, reviews, and feedback would be greatly appreciated.

Sponsor: The Google Summer of Code '23 program

Increasing MAXCPU

Contact: Ed Maste <>

The default amd64 and arm64 FreeBSD kernel configurations currently support a maximum of 256 CPUs. A custom kernel can be built with support for larger core counts by setting the MAXCPU kernel option. However, commodity systems with more than 256 CPUs are becoming available and will be increasingly common during FreeBSD 14’s support lifecycle. We want to increase the default maximum CPU count to 1024 to support these systems "out of the box" on FreeBSD 14.

A number of changes have been made to support a larger default MAXCPU, including fixing the userland maximum for cpuset_t at 1024. Changes have also been made to avoid static MAXCPU-sized arrays, replacing them with on-demand memory allocation.

Additional work is required to continue reducing static allocations sized by MAXCPU and addressing scalability bottlenecks on very high core count systems, but the goal is to release FreeBSD 14 with a stable ABI and KBI with support for large CPU counts.

Sponsor: The FreeBSD Foundation

SquashFS port for FreeBSD kernel

Contact: Raghav Sharma <>

SquashFS is a read-only file system that lets you compress whole file systems or single directories very efficiently. Support for it has been built into the Linux kernel since 2009 and is very common in embedded Linux distributions. The goal of this project is to add SquashFS support for the FreeBSD kernel, with the aim of being able to boot FreeBSD from an in-memory SquashFS file system.

Currently, the driver is compatible with the 13.2 FreeBSD release. The driver is able to correctly parse the SquashFS disk file with working mount(8) support. Linux SquashFS supports many compression options like zstd, lzo2, zlib, etc…​ based on the user’s preference, and of course, our driver supports all those compressions as well.

Planned future work includes adding directories, files, extended attributes, and symlinks read support. The project is still a work in progress under the mentorship from Chuck Tuffli and is expected to complete by the end of the Google Summer of Code program.

Sponsor: The Google Summer of Code 2023 program

Pf Improvements

Contact: Kajetan Staszkiewicz <>
Contact: Naman Sood <>
Contact: Kristof Provost <>

pf(4) is one of the firewalls included in FreeBSD, and is probably the most popular. pf was created by the OpenBSD project and subsequently ported to FreeBSD.

Backport OpenBSD Syntax

Kajetan introduced the OpenBSD syntax of "scrub" operations in "match" and "pass" rules. Existing rules remain supported, but now OpenBSD style "scrub" configuration is also supported.

pfsync Protocol Versioning

The pfsync(4) protocol version can now be configured, allowing for protocol changes while still supporting state synchronisation between disparate kernel versions. The primary benefit is to allow protocol changes enabling new functionality.

pfsync: Transport over IPv6

pfsync traffic can now be carried over IPv6 as well. Naman finished the work started by Luiz Amaral.


There is work in progress to support SCTP in pf. That support includes filtering on port numbers, state tracking, pfsync failover and returning ABORT chunks for rejected connections.

Sponsor: InnoGames GmbH
Sponsor: Orange Business Services
Sponsor: The FreeBSD Foundation

Network Interface API (IfAPI)

Contact: Justin Hibbits <>

Started back in 2014, the IfAPI (formerly DrvAPI) goal is to hide the ifnet(9) structure from network drivers. Instead, all accesses to members will go through accessor functions. This allows the network stack to be changed without recompiling drivers, as well as potentially allowing a single driver to support multiple versions of FreeBSD.

As of now this goal has been achieved in the base system, but several ports need to be updated to use the IfAPI. There is a tool to automate most of the conversion, in tools/ifnet/ Documentation is also forthcoming, but could use help on that. ifnet(9) needs a lot of cleanup, as even some information in it currently is out of date.

Sponsor: Juniper Networks, Inc.

Making Netgraph Lock-Free

Contact: Zain Khan <>

Netgraph helps us implement custom or complex networking functions by letting us arrange kernel objects called nodes in a graph connected using hooks. Nodes may perform a well-defined set of actions on incoming packets, and may send the output to another connected node. To 'send' a packet to a neighbour can also be seen as calling a function on that neighbouring node.

Now in a pre-SMP world, a thread (or the thread) would always see nodes as idle (not busy), so that their functions can immediately be called. Concurrency introduced the possibility of a busy node. Moreover, a journey of a packet also needs to take heed of changes in the structure of the graph, for example: the addressed node’s path may not remain intact due to no-longer-existing hooks or nodes in between, which may lead to cases such as referring to an object that has been freed. To counter such disasters, the existing source code uses a topology read-write mutex which protects data flow from restructuring events (and restructuring events from other restructuring events).

We want to regain the same smooth flow for data which existed when concurrent cpus were not a thing. That is, data should simply never wait every time there is a restructuring event. At the same time we also obviously do not want to give the kernel reasons to panic.

FreeBSD has its own set of concurrency-safe data structures and mechanisms. One of these mechanisms is Epoch. Epoch-based reclamation involves waiting for existing read-side critical sections to finish before the data structures need to be modified or reclaimed.

Because the base system is being modified, this is also going to affect the design choices made before, such as queuing on messages, reference counting.

This project involves a lot of testing. For now, some topology protection locks have been removed, and only simple graphs have been tested (with FreeBSD running on a VM). The real tests should be run on hardware with at least 4 CPU cores, I will do that when I get my hands on one.

Sponsor: The Google Summer of Code '23 program


Updating platform-specific features and bringing in support for new hardware platforms.

SIMD enhancements for amd64

Contact: Robert Clausecker <>

SIMD instruction set extensions such as SSE, AVX, and NEON are ubiquitous on modern computers and offer performance advantages for many applications. The goal of this project is to provide SIMD-enhanced versions of common libc functions (mostly those described in string(3)), speeding up most C programs.

For each function optimised, up to four implementations will be provided:

  • a scalar implementation optimised for amd64, but without any SIMD usage,

  • a baseline implementation using SSE and SSE2 or alternatively an x86-64-v2 implementation using all SSE extensions up to SSE4.2,

  • an x86-64-v3 implementation using AVX and AVX2, and

  • an x86-64-v4 implementation using AVX-512F/BW/CD/DQ.

Users will be able to select which level of SIMD enhancements to use by setting the AMD64_ARCHLEVEL environment variable.

While the current project only concerns amd64, the work may be expanded to other architectures like arm64 in the future.

Sponsor: The FreeBSD Foundation

Integrate mfsBSD into the release building tools

Contact: Soobin Rho <>

What is mfsBSD?

"mfsBSD is a toolset to create small-sized but full-featured mfsroot based distributions of FreeBSD that store all files in memory (MFS) [Memory File System] and load from hard drive, usb storage device or optical media. It can be used for a variety of purposes, including diskless systems, recovery partitions and remotely overwriting other operating systems."

Martin Matuska is both the author of the mfsBSD white paper and the maintainer of the mfsBSD repository.


This project creates an additional target of the weekly snapshots of -current and -stable versions of mfsBSD images in the src/release makefile. Currently, only the release versions of mfsBSD images are produced, which means they tend to get out of sync with the tools in base. This project aims to address that problem.


This is a GSoC 2023 (Google Summer of Code) project. As such, the official coding period is between May 29, 2023 and August 28, 2023. As a humble beginner in the open-source community, the author welcomes all comments / suggestions / pull requests in the project repository, which will be the location for all code throughout this period.

Sponsor: The Google Summer of Code '23 program


Updating cloud-specific features and bringing in support for new cloud platforms.

FreeBSD as a Tier 1 cloud-init Platform

Contact: Mina Galić <>

cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init support for operating systems other than Linux has been rather poor, and the lack of cloud-init support on FreeBSD is a hindrance to cloud providers who want to offer FreeBSD as a Tier 1 platform. To remedy the situation, this project aims to bring FreeBSD cloud-init support on par with Linux support. The broader plan is to lift support across all BSDs.

This quarter has been going quite slowly, but I have managed to deliver a new milestone:

  • Ephemeral Networking classes have been rewritten and made platform independent. These are used by several cloud providers to initialize a temporary network before retrieving the actual configuration.

  • cloud-init has been successfully tested on Vultr. I hope that with the next release I can convince Vultr to switch their FreeBSD images to cloud-init.

In addition to that, I have expanded rsyslog support for BSD. I’ve also added an rc script for cloud-init’s ds-identify, which should make zero-configuration setups orders of magnitude faster: ds-identify runs first and very quickly guesses the cloud provider the machine is running on. cloud-init then uses only that guess, instead of iterating and failing through a full list of all possible cloud providers. People building custom images can easily disable this (by removing /usr/local/etc/rc.d/dsidentify), and providing a specific listing themselves, shave off a few more milliseconds from their boot.

The next steps will be to keep hacking away at the network refactoring tasks, and to add LXD support for FreeBSD, so it can be included in CI tests. The latter will include work on LXD, as well as work on the FreeBSD virtio subsystem.

As always, I highly welcome early testers to checkout net/cloud-init-devel, and report bugs. Since the last report, cloud-init’s bug tracker has moved from Launchpad to GitHub, so this might reduce some friction.

Sponsor: The FreeBSD Foundation

OpenStack on FreeBSD

Contact: Chih-Hsin Chang <>
Contact: Li-Wen Hsu <>

This project aims to port key OpenStack components such as keystone, nova, and neutron, so that FreeBSD can function as an OpenStack host.

We started porting nova-novncproxy and nova-serialproxy to increase the ways to access the instance console. To lower the threshold for people who want to give it a try on the project, we also migrated our development environment from a physical machine to a virtual one. There is still a problem running bhyve VMs on top of Linux KVM. A detailed writeup for the issue can be found here. Other achievements include:

  • Sorting out network connectivity issues inside the instances

  • Able to spawn multiple instances

  • Porting from Python 3.8 to 3.9.

In the next quarter, we will continue working on the console proxy services to make the overall workflow more fluent.

The step-by-step documents for constructing a POC site can also be found in the docs repository. The patched version of each OpenStack component is under the same GitHub organization.

People interested in helping with the project can first help check the documentation by following the installation guide. Feedback and help are always welcome.

Sponsor: The FreeBSD Foundation

FreeBSD on Microsoft HyperV and Azure

Contact: Microsoft FreeBSD Integration Services Team <>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <>
Contact: Wei Hu <>
Contact: Souradeep Chakrabarti <>
Contact: Li-Wen Hsu <>

In this quarter, we have worked mainly on ARM64 architecture support and building and publishing images to Azure community gallery. There are some testing images available in the project’s testing public gallery, named FreeBSDCGTest-d8a43fa5-745a-4910-9f71-0c9da2ac22bf:

  • FreeBSD-CURRENT-testing

  • FreeBSD-CURRENT-gen2-testing

  • FreeBSD-CURRENT-arm64-testing

To use them, when creating a virtual machine:

  1. In Select an Image step, choose Community Images (PREVIEW) in Other items

  2. Search FreeBSD

Work in progress tasks:

  • Automating the image building and publishing process and merge to src/release/.

  • Building and publishing ZFS-based images to Azure Marketplace

    • All the required codes are merged to main branch, and can create ZFS-based images by specifying VMFS=zfs.

    • Need to make the build process more automatic and collaborating with release engineering to start generating snapshots.

  • Building and publishing Hyper-V gen2 VM images to Azure Marketplace

  • Building and publishing snapshot builds to Azure community gallery

The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft.

Wei Hu and Souradeep Chakrabarti in Microsoft are working on several tasks sponsored by Microsoft:

Open tasks:

Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else

FreeBSD on EC2

Contact: Colin Percival <>

FreeBSD is available on both x86 (Intel and AMD) and ARM64 (Graviton) EC2 instances. Work continues to ensure that upcoming instance types will be supported, including the recently announced M7a "EPYC" instances, which should be supported in FreeBSD 14.0-RELEASE.

Weekly FreeBSD snapshots were recently changed from "UEFI" boot mode to "UEFI Preferred" boot mode, allowing them to gain the boot performance improvement offered by UEFI while still supporting "bare metal" and "previous generation" instance types which are not compatible with UEFI. This change will be present in FreeBSD 14.0-RELEASE.

The EC2 boot scripts were recently updated to support IMDSv2. This change will be present in FreeBSD 14.0-RELEASE.

If users of FreeBSD 13.2 require any of these updates, the author can provide FreeBSD "13.2-RELEASE plus updates" AMIs.

This work is supported by Colin’s FreeBSD/EC2 Patreon.


Noteworthy changes in the documentation tree, manual pages, or new external books/documents.

Documentation Engineering Team

Contact: FreeBSD Doceng Team <>

The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see the FreeBSD Doceng Team Charter.

During this quarter:

  • fernape@ has been appointed as a new Doceng team member.

  • The www/gohugo port maintainership has been transferred to doceng@ since it is a critical part of our documentation infrastructure. This was agreed with the former maintainer.

  • Improvements to the translation workflow (described in the following sections).

Porter’s Handbook

USES=nextcloud has been documented.

FDP Primer

A new chapter focusing on Weblate has been added to the FreeBSD Documentation Project Primer for New Contributors. This comprehensive chapter provides step-by-step guidance on joining the FreeBSD translators team, both for translating online on Weblate and offline. It offers valuable insights and practical suggestions for efficient translation, proofreading, and testing processes. Furthermore, this chapter equips contributors with the necessary knowledge to formally submit their translations to the documentation repository, ensuring a seamless integration of their work.

FreeBSD Translations on Weblate

Q2 2023 Status

The FreeBSD Weblate instance now operates on a dedicated server, significantly improving its speed and enhancing the efficiency of translation work. Our heartfelt appreciation goes to ebrandi@ for providing this hardware upgrade.

  • Chinese (Simplified) (zh-cn) (progress: 7%)

  • Chinese (Traditional) (zh-tw) (progress: 3%)

  • Dutch (nl) (progress: 1%)

  • French (fr) (progress: 1%)

  • German (de) (progress: 1%)

  • Indonesian (id) (progress: 1%)

  • Italian (it) (progress: 5%)

  • Korean (ko) (progress: 32%)

  • Norwegian (nb-no) (progress: 1%)

  • Persian (fa-ir) (progress: 3%)

  • Polish (progress: 1%)

  • Portuguese (pt-br) (progress: 22%)

  • Sinhala (si) (progress: 1%)

  • Spanish (es) (progress: 33%)

  • Turkish (tr) (progress: 2%)

We want to thank everyone that contributed, translating or reviewing documents.

And please, help promote this effort on your local user group, we always need more volunteers.

FreeBSD Handbook working group

Contact: Sergio Carlavilla <>

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla <>

Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work is divided into four phases:

  1. Redesign of the Documentation Portal

    Create a new design, responsive and with global search. (Complete)

  2. Redesign of the Manual Pages on web

    Scripts to generate the HTML pages using mandoc. (Complete) Public instance on

  3. Redesign of the Ports page on web

    Ports scripts to create an applications portal. (Work in progress)

  4. Redesign of the FreeBSD main website

    New design, responsive and dark theme. (Work in progress)


Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.

KDE on FreeBSD

Contact: Adriaan de Groot <>

The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine.

The KDE team (kde@) is part of desktop@ and x11@, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphical desktop workstation. The notes below describe mostly ports for KDE, but also include items that are important for the entire desktop stack.


Qt5 ports had various updates:

  • devel/qt5-webengine was repaired when building with Clang 16. This is in preparation for the upcoming release of FreeBSD 14.

  • devel/qt5-qmake was repaired to deal with an edge case where installing qmake on an otherwise Qt-less system would cause weird errors.

Qt6 ports had various updates:

  • devel/qt6-tools was repaired when building with Clang 16. This is preparation for the upcoming release of FreeBSD 14.

The accessibility/at-spi2-core port — essential for accessible technologies on the desktop — was updated to release 2.48.0.

The accessibility/at-spi2-core port now has better support for non-X11 desktops. This is an improvement for Wayland-based systems. Thanks to Jan Beich for landing that.

The graphics/poppler port — a base for many PDF viewers — was updated to 23.05.

The ports-mgmt/packagekit-qt port is a new addition to the tree to pave the way for graphical package managers on FreeBSD.

KDE Stack

KDE Gear releases happen every quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release every month as well. These (large) updates land shortly after their upstream release and are not listed separately.

  • KDE Frameworks updated to 5.105, .106 and .107.

  • KDE Gear updated to 23.04.0, then .1 and .2 with bugfixes.

  • KDE Plasma Desktop was updated to version 5.27.4, then .5 and .6 with bugfixes.


  • graphics/ikona, an icon-viewer written in Rust with Qt bindings, has been abandoned upstream.

  • polish/kadu, a chat application once popular in Poland, is deprecated and upstream has disappeared.

  • sysutils/plasma5-ksysguard, a system monitoring application, is deprecated upstream and will no longer update.


  • astro/kstars, an interactive planetarium, was updated to release 3.6.4.

  • devel/qcoro, a C++ coroutines implementation, was updated to 0.9.0.

  • devel/qtcreator, an integrated development environment for Qt, C++, and more, was updated to release 10.0.2.

  • games/gcompris-qt, an education suite for children aged 3-12, was updated to release 3.2.

  • graphics/kphotoalbum, a photo album and display utility, was updated to release 5.10.0.

  • net-im/tokodon, a Mastodon social network client, joins KDE Gear.

  • textproc/kdiff3, a text-differencing utility, was updated to release 1.10.1.

New Software:

  • devel/kommit, a Git client, was added. It is a rename of previous package gitklient.

  • multimedia/kasts is a new podcast-listening and enjoyment application from the KDE community.

  • textproc/arianna is a mobile-oriented e-book reader from the KDE community that makes reading FreeBSD documentation a joy.

GCC on FreeBSD

Contact: Lorenzo Salvadore <>

Upstream has released GCC 13. As announced in the past status report, I plan to attempt an update of GCC_DEFAULT right from the first GCC 13 release, thus much of this quarter’s work has been in preparation of this.

With the release of GCC 13.1 (first GCC 13 release: I remind that GCC counts minor version releases starting from 1), two new ports have been created in the ports tree:

The *-devel ports

Support for .init_array and .fini_array has been enabled. FreeBSD supports both since commit 83aa9cc00c2d.

The default bootstrap option on i386, amd64, and aarch64 has been reverted from LTO_BOOTSTRAP to STANDARD_BOOTSTRAP:

  • LTO bootstrap produces too many failures on the package builders for those architectures

  • LTO_BOOTSTRAP remains available for users who want it.

Those changes will be forwarded to the production ports.

The production ports

Upstream has released GCC 13, for which the new port lang/gcc13 has been created. GCC 11 and GCC 12 have been updated upstream and a new release of GCC 10 is planned. All corresponding ports now need to be updated.

To ease the work of both ports maintainers and users, I plan to test and update together all the following changes:

  • updates of lang/gcc10, lang/gcc11, lang/gcc12;

  • update of GCC_DEFAULT to 13;

  • enabling of .init_array and .fini_array on the production ports;

  • switching back from LTO_BOOTSTRAP to STANDARD_BOOTSTRAP on the production ports.

This will provide the following advantages:

  • more testing with less exp-runs;

  • fewer builds for ports users.


Contact: Puppet Team <>

Puppet is a Free Software configuration management tool, composed of a source of trust (Puppet Server) that describes the expected configuration of machines with a domain-specific language, and an agent (Puppet Agent) on each node which enforces that the actual configuration matches the expected one. An optional database (PuppetDB) can be setup for reporting and describing advanced schemas where the configuration of a machine depends on the configuration of another one.

The Puppet team is maintaining ports for Puppet and related tools.

Puppet 8 has been recently released and has been added to the ports tree.

Puppet 6 has reached End of Life and has been deprecated. It is now expired. Users of Puppet 6 are therefore advised to update to Puppet 7 or Puppet 8.

For now, Puppet 7 remains the default Puppet version for ports depending on Puppet. The Puppet Community is hard at work making sure the various Puppet modules work with the latest code and at the time of writing this report, updating to Puppet 8 may be challenging. The situation is getting better every day, and we expect to switch to Puppet 8 as the default version of Puppet in a few months, when the wave of module updates is finished.

MITRE Caldera on FreeBSD

Contact: José Alonso Cárdenas Márquez <>

MITRE Caldera is a cybersecurity platform designed to easily automate adversary emulation, assist manual red teams, and automate incident response.

It is built on the MITRE ATT&CK® framework and is an active research project at MITRE.

MITRE Caldera (security/caldera) was added to the ports tree in April 2023. This port includes support for the Atomic Red Team Project used by the MITRE Caldera atomic plugin.

The main goal of this work is enhancing visibility of FreeBSD as a useful platform for information security or cybersecurity.

Additionally, you can test a MITRE Caldera infrastructure easily using or from AppJail. AppJail is a good tool for managing jail containers from the command line.

People interested in helping with the project are welcome.

Current version: 4.2.0

To Do

Wazuh on FreeBSD

Contact: José Alonso Cárdenas Márquez <>

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments.

The Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Wazuh features include full integration with Elastic Stack and OpenSearch, providing a search engine and data visualization tool through which users can navigate security alerts.

Wazuh porting to FreeBSD was started by Michael Muenz. His first Wazuh addition to the ports tree was security/wazuh-agent in September 2021. In July 2022, I took maintainership of this port and started porting other Wazuh components.

On FreeBSD, security/wazuh-manager and security/wazuh-agent are compiled from Wazuh source code. security/wazuh-indexer is an adapted textproc/opensearch used for storing agents data. security/wazuh-server includes FreeBSD-oriented adaptions to configuration files. Runtime dependencies comprise security/wazuh-manager, sysutils/beats8 (filebeat), and sysutils/logstash8. security/wazuh-dashboard uses an adapted textproc/opensearch-dashboards and the wazuh-kibana-app plugin generated from wazuh-kibana-app source code for FreeBSD.

The main goal of this work is enhancing visibility of FreeBSD as a useful platform for information security or cybersecurity.

Additionally, you can easily test a Wazuh single-node infrastructure (All-in-one) using or from AppJail. AppJail is a good tool for managing jail containers from the command line.

People interested in helping with the project are welcome.

Current version: 4.4.4


Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions.

Contact: Mina Galić <>, an unofficial repository for the FreeBSD PkgBase project, is back alive.

As a service, was inspired by, which provided freebsd-update(8) for STABLE and CURRENT branches. itself has gone on hiatus, so it was all the more reason to bring back

Right now, we provide builds for:

  • FreeBSD 13.2-RELEASE

  • FreeBSD 13-STABLE

  • FreeBSD 14-CURRENT

each for the following platforms:

  • amd64

  • aarch64

  • armv7

  • i386

You may notice that RISCv64 is gone for now.

The hardware is a powerful VPS in Vultr. The server and the jails running build jobs and serving packages are "self-hosting", meaning they were installed and are kept up-to-date with PkgBase.

Because we have not figured out yet how to configure Vultr’s IPv6 in FreeBSD jails, is not available over IPv6 for now. If you have experience with that, please contact us!

Along with users and testers, we still highly encourage copy-cats.

Hardware for PkgBase is kindly sponsored by a member of the FreeBSD community.

Containers and FreeBSD: Pot, Potluck and Potman

Contact: Luca Pizzamiglio (Pot) <>
Contact: Bretton Vine (Potluck) <>
Contact: Michael Gmelin (Potman) <>

Pot is a jail management tool that also supports orchestration through Nomad.

During this quarter, Pot 0.15.5 was released, containing a number of bugfixes and features to set attributes (i.e. jail sysctl variables) from various contributors. It will be available in the 2023Q3 quarterly package set.

Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a repository of Pot flavours and complete container images for usage with Pot and in many cases Nomad.

All Potluck containers have been rebuilt as FreeBSD 13.2 based images and are signed with Pot signify now.

A Beginner’s Guide to Building a Virtual Datacenter on FreeBSD with Ansible, Pot and More has been written, explaining how a complex environment based on Pot and Potluck can be deployed with Ansible playbooks, including example nodes like MariaDB, Prometheus, Grafana, nginx, OpenLDAP or Traefik and container orchestration managed by Nomad and Consul.

A patch by the pot team to improve Nomad security, a scheduler and orchestrator which supports Pot through sysutils/nomad-pot-driver, has been accepted upstream and will be part of Nomad 1.6.0.

As always, feedback and patches are welcome.

Sponsor: Honeyguide Group

Last modified on: July 28, 2023 by Graham Perrin