Newshot Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.
FreeBSD, CRA, EuroBSDCon, and Security Team
Links: Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev FreeBSD Foundation URL: https://freebsdfoundation.org FreeBSD Security Information URL: https://www.freebsd.org/security/
Contact: Pierre Pronchery <[email protected]>
This is my second quarter in the FreeBSD Foundation as part of Alpha-Omega’s Security Engineers In Residence (SEIRs) initiative. Thanks to the input received from the Security Team, I have integrated a staging instance of Forgejo with a self-hosted LLM, demonstrating the potential of new capabilities for the Security Team, without breaching any confidentiality requirements. This system is capable of dealing with incoming security vulnerability reports, by:
- Drafting an initial response for the submitter
- Issuing an immediate, automated analysis of the issue submitted
- Preparing a template for an eventual Security Advisory (SA) or Errata Notice (EN)
- Checking the SA or EN drafts for conformity
- Automatically signing the final SA, EN, and corresponding assets
- Uploading the outcome where appropriate
This is implemented like a typical, modern CI/CD system with Forgejo’s runner tool as a GitHub-compatible workflow. The aim is to leverage LLM capabilities for our processes, in accordance with the current workflow, without compromising on confidentiality nor on the necessity for quality review by us mortal members of the security team.
Significant polishing is still required, but the corresponding instance in production should be useful even without the LLM part. The automation of the more repetitive tasks of the workflow is expected to help us deal with the steady amount of incoming reports, and to extend capabilities from our individual minds into the team as a whole.
In parallel, I have not spared my efforts towards compliance with the European Cyber Resilience Act (CRA) for the FreeBSD Project. After importing pkgconf in FreeBSD’s base system during the last quarter, I went through a number of iterations for the framework generating Software Bill of Material (SBOM) artefacts during the build. Prepared together with Tuukka Pasanen, the framework is available for review in D56474 and I now believe it to be a serious candidate for integration. I would like to thank everyone who has been providing feedback already! This has helped tremendously to find a balance that feels more right than at any time earlier — at least to me. A separate request for review for the meta-data is now available as well, D60352, which currently generates a total of 218 artefacts for an amd64 build. The balance consists of about one artefact per base package generated, as well as one artefact per library actually used during the build. This way, the complete chain of dependencies can be tracked, while keeping the granularity close to individual third-party projects or internal components.
I would also like to extend my thanks to Alice Sowerby and to Peter Hansteen for an awesome workshop about CRA compliance during EuroBSDCon 2026 in Brussels, this past September 2026. If you have missed it, you may be in luck, as we are gearing up to deliver it again at a future event. Do not hesitate to reach out to us if you are interested, together with your rough location and flexibility for travel, so we can have a more accurate impression of the times and places we should aim for.
Sponsor: Alpha-Omega, The FreeBSD Foundation
Cyber Resilience Act (CRA) Readiness Project
Links: Cyber Resilience Act Readiness URL: https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness
The Foundation is running a project through 2026 to actively prepare the FreeBSD Foundation, Project, and community for the EU Cyber Resilience Act. There are six main areas of focus: Security and Vulnerability Handling, SBOM Toolchain, Public Documentation, Community Legislative Engagement, Public Project Repository, and Communications.
Over Q3, the project has continued to move from planning into implementation, with particular focus on readiness for the CRA’s vulnerability and incident reporting requirements that came into force for manufacturers on September 11, 2026.
The Foundation has created a cyber security policy and CRA reporting protocol to support the Foundation in meeting its obligations as an open source software steward. Both have been developed with input from the FreeBSD Core and Security Teams and document how the Foundation will work with the Project and respond if CRA reporting obligations are triggered for the Foundation as a steward. Note that the European Commission has clarified that reporting obligations for stewards begin on December 11, 2027. These documents will remain internal resources for the time being.
Technical work on the Software Bill of Materials (SBOM) toolchain has continued through development, testing, and review. The proposed approach for generating SBOMs for the FreeBSD base system is being refined in response to feedback and still requires further review and supporting changes before integration. Work is also progressing across the wider SBOM ecosystem, both through the Foundation and in the community, including planned support for ports, SPDX-compatible license information, and CycloneDX and SPDX SBOM support in pkgconf.
Public CRA guidance is now available on the FreeBSD Foundation website, providing an overview of the legislation alongside dedicated guidance for FreeBSD business users and community members. This gives FreeBSD users clearer information about how the CRA may affect them, where their responsibilities may sit, and how to work with FreeBSD in meeting their CRA obligations.
The Foundation has continued to engage with the FreeBSD and wider open source communities, especially the Eclipse Foundation’s Open Regulatory Compliance (ORC) working group. At EuroBSDCon 2026, we collaborated with Peter Hansteen to run a day-long CRA and SBOM tutorial. We also presented an update on this project at the FreeBSD Developer Summit.
Project updates and meeting notes continue to be published through the public project repository. As we move into Q4, the focus will be on progressing the SBOM implementation and upstream work, improving the discoverability of our public CRA guidance, and working with the FreeBSD Project to identify key manufacturer needs that relate to their CRA obligation to adopt a secure software lifecycle by December 11, 2027.
FreeBSD Software Bill of Materials (SBOM)
Links: sys/arm/arm/busdma_machdep.c: Correct SPDX-License-Identifier URL: https://reviews.freebsd.org/D59528 sys/powerpc/powerpc/busdma_machdep.c: Correct SPDX-License-Identifier URL: https://reviews.freebsd.org/D59527 sys/powerpc/powerpc/busdma_bounce.c: Correct SPDX-License-Identifier URL: https://reviews.freebsd.org/D59526 sys/x86/x86/busdma_machdep.c: Correct SPDX-License-Identifier URL: https://reviews.freebsd.org/D59525 sys/x86/x86/busdma_bounce.c: Correct SPDX-License-Identifier URL: https://reviews.freebsd.org/D59524 sys/kern/subr_busdma_bounce.c: Correct SPDX-License-Identifier URL: https://reviews.freebsd.org/D59523 D60352 URL: https://reviews.freebsd.org/D60352 D60441 URL: https://reviews.freebsd.org/D60441
Open upstream SPDX license identifier PRs: ATF PR#128 URL: https://github.com/freebsd/atf/pull/128 bmake NetBSD GNATS#60308 URL: https://gnats.netbsd.org/60308 LDNS ISSUE#305 URL: https://github.com/NLnetLabs/ldns/issues/305 Less PR#792 URL: https://github.com/gwsw/less/pull/792 Libarchive PR#3129 URL: https://github.com/libarchive/libarchive/pull/3129 LibCBOR ISSUE#430 URL: https://github.com/PJK/libcbor/issues/430 Libevent ISSUE#1864 URL: https://github.com/libevent/libevent/issues/1864 LibPCAP PR#1689 URL: https://github.com/the-tcpdump-group/libpcap/pull/1689 LibUCL PR#386 URL: https://github.com/vstakhov/libucl/pull/386 TCSH Mantis#777 URL: https://bugs.astron.com/view.php?id=777
Contact: Tuukka Pasanen <[email protected]>
The FreeBSD Software Bill of Materials (SBOM) effort has been continued during Q3 2026. At last, getting SBOM into FreeBSD source is manifesting itself and hopefully will be finalized in Q4. Thanks to Pierre Pronchery, there is a Phabricator review ongoing: D60352 for FreeBSD source. Also, ports have one for reviewing: D60441 made by Mathieu Arnold.
As an option for SBOM output, there are currently available SPDX 2.2 and Lite 3.0.1. CycloneDX SBOM tool is in work in progress and still needs some love to be as qualified as the output for SPDX. In the future, all SBOM outputs will be under one tool, which will be named sbomtool, and as both solutions rely on pkgconf, they will have CycloneDX when it lands in FreeBSD source.
Additionally, several new SPDX License Identifiers have been accepted. All three are in FreeBSD source: BSD-2-Clause-pos-unchanged BSD-Source-Code-no-disclaimer * BSD-Source-alt-GPL
There are several updates from BSD-2-Clause to BSD-Source-beginning-file in review:
- sys/arm/arm/busdma_machdep.c: Correct SPDX-License-Identifier
- sys/powerpc/powerpc/busdma_machdep.c: Correct SPDX-License-Identifier
- sys/powerpc/powerpc/busdma_bounce.c: Correct SPDX-License-Identifier
- sys/x86/x86/busdma_machdep.c: Correct SPDX-License-Identifier
- sys/x86/x86/busdma_bounce.c: Correct SPDX-License-Identifier
- sys/kern/subr_busdma_bounce.c: Correct SPDX-License-Identifier
Additionally, many third-party repositories have received SPDX License Identifiers, such as libxo (thanks to Juniper for that), and others. Some projects do not want headers, and some are still in active development.
If you want to help with this effort:
- Review Phabricator changes. SPDX License Identifier corrections are at a very low level to review.
- When pkgconf CycloneDX is available, help review and test it.
Sponsor: FreeBSD Foundation
Capsicumize fts(3)
Links: fts(3) manual page URL: https://man.freebsd.org/cgi/man.cgi?fts(3)
Contact: Jitendra Bhati <[email protected]> Contact: Alan Somers <[email protected]>
The fts(3) directory traversal library, used by find(1), rm(1), ls(1), chflags(1) and other utilities, historically relied on path-based syscalls that fail in capsicum(4) capability mode.
This quarter fts gained a new fts_openat() entry point that accepts a pre-opened directory descriptor, a per-entry fts_dirfd field, and a conversion of its internals to fd-relative operations, with ABI compatibility preserved through ELF symbol versioning. A traversal can now run entirely inside a Capsicum sandbox.
As a first consumer, chflags was capsicumized to perform its work through chflagsat() on descriptors opened before entering capability mode, confining it to the hierarchies named on its command line.
This work was completed as a Google Summer of Code 2026 project.
Sponsor: Google Summer of Code 2026
Full CPUID Control for bhyve
Contact: Hans Rosenfeld <[email protected]>
Project Overview
Ongoing work on this project aims to integrate the existing proof-of-concept work into FreeBSD, and to add the following usability features:
- a user-friendly configuration method to override individual bits, parts or even whole CPUID functions as needed, while keeping the rest of the host CPUID information or a pre-defined CPUID configuration
- a user-friendly configuration method for the hypervisor signature reported by bhyve
- a set of predefined CPUID configurations based on common x86 architecture levels, perhaps also including a set of CPUID data for a few real CPU models, and a user-friendly configuration method to choose one for a VM
Changes during the last quarter
There was a last minute change to the configuration syntax. Instead of using two different options cpuid.enable and cpuid.disable to enable or disable features by name, there is now a single cpuid.features option. This option accepts feature name, either prefixed with - to disable them, or prefixed with + or no prefix to enable a feature.
In addition to the abstract x86 architecture models, a number of CPU models have been implemented as pre-defined configuration file snippets. This currently ends with the Icelake generation for Intel and the Bulldozer generation for AMD.
Many more cpuid configuration options have been introduced to ease writing of CPU model configurations, such as cpuid.brand for the CPU Brand String or cpuid.vendor to override the vendor identification.
The constraints checks have been extended to allow defining bitmasks for values that can only be numerically lowered.
A new configuration option cpuid.check has been introduced to override the default action regarding the constraints checks. It takes the values fail (the default), warn, none, and fix.
Default cache configurations have been added to the x86 architecture models and all pre-defined CPU models.
A new cpuid.hypervisor option allows easy overriding of the hypervisor identification in CPUID function 0x40000000. The real hypervisor identification and feature flags can still be queried by guests from CPUID function 0x40000100.
Plans for the next quarter
- Add more modern pre-defined CPU models
- Update manpages bhyve(8), bhyve_config(5), and bhyvectl(8).
- Get the whole wad reviewed and committed into FreeBSD.
A bhyve management GUI written in Freepascal/Lazarus
Links: Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/ Bhyvemgrd URL: https://github.com/alonsobsd/bhyvemgrd/
Contact: José Alonso Cárdenas Márquez <[email protected]>
Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools, mostly installed on base system, and some installed from ports/packages. The main goal is to be a desktop application with focus on desktop users to easily and quickly setup and run virtual machines on FreeBSD hosts.
Starting with version v2.0.0, bhyvemgr was migrated to client/server architecture. As a result, a server component was developed. This new component is called bhyvemgrd.
Bhvemgrd supports two ways to run privileged tasks: mac_do/mdo (FreeBSD >= 140000) and mac_do/setcred/exec_paths (only for FreeBSD >= 1501501). The process itself run under an unprivileged bhyvemgrd user.
During last two quarters, there were many bugfixes and improvements to Bhyvemgr.
These are some highlights that were added:
- Add new operating system options
- Add support to use VNC unix sock (vnc.sock) when FreeBSD >= 1500509
- Add support for storage snapshot (only if zfs is enable)
- Improve TPM support
- Move to client/server architecture (unixsocket, json, etc). The bhyvemgr keeps like a client and a new bhyvemgrd app is used like a server.
- Remove privileged functions/procedures. Now they are part of bhyvemgrd.
- Remove sudo/doas support. It is not necessary anymore because privileged tasks will trigger from bhyvemgrd service.
- Remove FreeBSD 13.x support
- Replace remote-viewer support (virt-viewer) with vncviewer (tigervnc-viewer). The vncviewer needs less dependencies and it can be ligther than virt option.
- Other fixes, improvements and changes
Bhyvemgr and Bhyvemgrd supports aarch64 from 15.x to 16-CURRENT and amd64 from FreeBSD 14.x to 16-CURRENT. Bhyvemgr can be compiled or installed from sysutils/bhyvemgr with gtk2, qt5, or qt6 interface support. Bhyvemgrd can be compiled or installed from sysutils/bhyvemgrd.
People interested in helping or supporting the projects are welcome.
Current bhyvemgr version: 2.1.0 Current bhyvemgrd version: 1.2.0
Sponsor: https://paypal.me/alonsocbsd
Desktop Script for bsdinstall
Links: Laptop Support and Usability Project Task URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/25 Project repository URL: https://gitlab.com/alfix/kde-installer-dialogs
Contact: Alfonso S. Siciliano <[email protected]>
The goal of this project is to provide a simple feature in bsdinstall(8), the FreeBSD system installer, to install and configure a graphical environment. The installer should ask users whether they want to install a desktop environment and, if so, automatically install and configure everything needed with minimal or no user intervention. After reboot, users should be presented with a graphical login screen.
In the first 2026 status report, a possible solution was described: a shell script of approximately 400 lines of code to install and automatically configure the components required for a graphical desktop environment, including GPU drivers, Xorg, KDE Plasma, and SDDM. After a call for testing, which received a significant amount of feedback from users, review D56167 was submitted to add the new desktop script to bsdinstall.
After the review was submitted, several discussions took place about the proposed implementation. As a result of the review, it was requested to split the script into smaller components and move part of its functionality into separate ports. The review, D56167, is now obsolete. Several possible approaches were then analyzed and tested.
The chosen solution is to create new ports with flavors.
The base port provides the tools to build menus and/or return to the script a list of packages to install. The menu utilities are implemented as shell scripts because the design of a Lua API for the text user interfaces is still in progress.
Each flavor provides a pkg-post-install-lua(5) script to configure the package installed on the new system. pkg-post-install-lua was chosen instead of the pkg-post-install(5) shell script because it will make it easier to reuse the code if it becomes necessary to use pkg-trigger(5) in the future.
The following four new ports with flavors, with a total of 26 packages, have been created and submitted to Bugzilla:
- x11/bsdinstall-desktop PR298402 Base port utilities: bsdinstall-desktop-checks, bsdinstall-desktop-users with menu support. Flavor: -audio.
x11/bsdinstall-desktop PR298402
- Base port utilities: bsdinstall-desktop-checks, bsdinstall-desktop-users with menu support.
- Flavor: -audio.
- graphics/bsdinstall-gpu PR298413 Base port utility: bsdinstall-gpu with menu support. Flavors: -amd, -drm, -intel, -nv304, -nv340, -nv390, -nv470, -nv580, -nv595, -nv610, -nvaddons, -nvoptimus, -radeon, -scfb, -vbox, -vesa, -vmware.
graphics/bsdinstall-gpu PR298413
- Base port utility: bsdinstall-gpu with menu support.
- Flavors: -amd, -drm, -intel, -nv304, -nv340, -nv390, -nv470, -nv580, -nv595, -nv610, -nvaddons, -nvoptimus, -radeon, -scfb, -vbox, -vesa, -vmware.
- x11/bsdinstall-de PR298442 Base port utility: bsdinstall-de. Flavors: -kde, -wireplumber.
x11/bsdinstall-de PR298442
- Base port utility: bsdinstall-de.
- Flavors: -kde, -wireplumber.
- x11/bsdinstall-dm PR298455 Base port utility: bsdinstall-dm with menu support. Flavors: -ly, -sddm.
x11/bsdinstall-dm PR298455
- Base port utility: bsdinstall-dm with menu support.
- Flavors: -ly, -sddm.
A new draft of the desktop script has also been completed in the project repository. It is significantly different from the original script and is now approximately 100 lines of code. A new review to add the desktop script to bsdinstall will be submitted after the new ports have been added to the Ports Collection.
This is still an experimental feature. In the future, depending on user interest and feedback, the desktop script can be further improved to support additional desktop environments and graphical tools.
Sponsor: The FreeBSD Foundation
Sylve — A Unified System Management Platform for FreeBSD
Links: Website URL: https://sylve.io GitHub URL: https://github.com/AlchemillaHQ/Sylve CI URL: https://sylve-ci.alchemilla.io Discord URL: https://discord.gg/bJB826JvXK
Contact: Hayzam Sherif <[email protected]>
Sylve is a modern, unified system management platform for FreeBSD. It provides an integrated web interface for managing virtual machines (via Bhyve), Jails, the networking around them, and ZFS storage.
The backend is implemented in Go, while the frontend is built with Svelte. The project emphasizes a minimal system footprint. By default, it does not require any packages outside of the base system.
Optional runtime dependencies, required only when their respective features are used, include:
- devel/libvirt for virtualization
- devel/qemu for disk image management
- Samba 4.x (for example net/samba424) for SMB file sharing
- sysutils/swtpm for TPM emulation support
- dns/dnsmasq for DHCP and DNS services
The port pulls in these dependencies for convenience to the user, but by itself, Sylve needs no dependencies to run.
Q3 Progress Highlights
We published two tagged releases this quarter: v0.3.0 on August 24, which shipped the networking, migration, replication, and backup work reported last quarter, and v0.3.1 on September 7, the latter improving cluster recovery, backups, migration, and guest storage management.
- Migration between cluster nodes now transfers the bulk of the ZFS data while the workload is still online, followed by a final incremental transfer and a guarded cutover.
- Backups now commit related datasets and VM disks as coordinated generations, with stronger restore and recovery workflows.
- Deeper ZFS and ARC telemetry and scheduled S.M.A.R.T. tests were added.
- VM storage workflows were redesigned in v0.3.1, with explicit semantics for ejecting and deleting attachments.
- A protected local CLI and interactive console were added for common VM, Jail, networking, and lifecycle operations.
- Certificate and Dynamic DNS management are built in, including free Sylve.app hostnames with managed TLS, plus Cloudflare and Namecheap support.
- The user documentation received a major overhaul, with task-oriented guides for all major features.
- Sylve now requires libvirt 12.5.0 or newer for VM management; FreeBSD 15.0 or newer remains required.
The FreeBSD Foundation has expanded its support for Sylve with a new grant for parts of the next phase of the platform.
The next quarter(s) will bring:
- Native OCI container management through Podman.
- An App Gallery with templates for deploying applications in Jails and containers.
- NFS sharing and automatic ZFS dataset tuning.
- A mobile app for managing clusters, operating-system updates from the interface, and ZFS scrub schedules.
- End-to-end testing and clearer migration documentation.
- A simplified interface for beginners.
Sponsors: The FreeBSD Foundation, Alchemilla Ventures (Development), IPTechnics LLC (Infrastructure & Testing)
Vision Accessibility
Links: Accessibility Handbook URL: https://docs.freebsd.org/en/books/accessibility/ Project repository URL: https://gitlab.com/alfix/freebsd-accessibility/ LearnBraille URL: https://gitlab.com/-/snippets/6065143 bsddialog URL: https://gitlab.com/alfix/bsddialog
Contact: Accessibility <[email protected]> Contact: Alfonso S. Siciliano <[email protected]>
Vision Accessibility is a project focused on improving visual accessibility in FreeBSD by documenting, developing, and integrating assistive technologies for blind and visually impaired users.
High-contrast Theme
During this quarter, work focused mainly on Milestone 2: creating new accessible themes for TUI utilities in the FreeBSD base system, with the ability to select one during the OS installation.
The next version of bsddialog was developed as part of this work, with a focus on improving its theming support. The theming code was reorganized and improved, and the bsddialog_theme.h API was extended to allow applications to select and customize themes more easily and automatically.
In particular, the library initialization process now uses bsddialog_get_auto_theme(), which automatically detects the theme to use. If available, the theme can be selected through a centralized system-wide or user-specific configuration file. This allows utilities in the FreeBSD base system, such as tzsetup(8) and bsdinstall(8), as well as ports such as ports-mgmt/portconfig, to use the same theme configuration without requiring individual changes to each application.
Several accessibility-oriented themes were also improved or added:
- Improved the built-in black-and-white theme. It was originally designed for terminals without color support, but it is also useful for presenting information without relying on colors alone.
- Added a theme without red, using black, blue, cyan, white, and yellow.
- Added a theme without yellow and blue, using black, green, red, and white.
- Added a new high-contrast theme, using black, magenta, white, and yellow.
The new functionality has been documented in the manual pages, with new examples, and in the bsddialog CHANGELOG.
The design and implementation phases have been completed, and testing is now starting. The new functionality is currently available only in the main branch of the bsddialog repository.
The next steps are to complete testing, release version 1.2, update the devel/bsddialog port, and import the new version into FreeBSD BASE.
Braille display devices
During this quarter, a HumanWare BrailleNote Apex was acquired for use in the upcoming milestones. A suitable charger was received and the device was successfully tested. The Braille display and keyboard are working, as is the built-in speech synthesizer.
Although the Braille subsystem is planned for a future milestone, initial experimentation has already started because designing and integrating such a subsystem is a complex task. These first tests are intended to provide practical information for its future design and implementation.
The BrailleNote Apex is not simply a Braille display, but a Braille notetaker running Windows Embedded CE 6.0. It provides a one-dimensional user interface through KeySoft, with applications such as a word processor, email, web browsing, and other functionality. The Apex was also connected to an external monitor through VGA, which made it easier to explore and better understand its functionality.
Using the Apex requires familiarity with Braille, both for writing through the Braille keyboard and for reading through the Braille display. For this reason, LearnBraille was also developed and used. It is a simple Lua script that uses devel/liblouis to provide a quiz for practicing Braille characters.
The Apex was connected to FreeBSD through USB and used in its "Screen Reader Terminal" mode, which allows the device to operate as a Braille display connected to another computer. The device is recognized by uipaq(4), and communication is provided through the man:ucom interface[4]. This is consistent with the device’s architecture, as the Apex runs Windows Embedded CE 6.0.
Initial communication tests were successful in both directions. Data was sent from FreeBSD to the Braille display, including a simple "Hello World, FreeBSD!" message rendered on the Braille cells. Characters typed on the Braille keyboard were also received by FreeBSD. In this direction, each Braille character is represented by one byte, with its bits corresponding to the Braille dots.
Further tests, documentation, and information about the progress and results of this work will be provided in future reports.
Sponsor: The FreeBSD Foundation
x11appjail: Tool for creating, verifying, installing, and running AppJails
Links: x11appjail on GitHub URL: https://github.com/DtxdF/x11appjail Contact: Jesús Daniel Colmenares Oviedo <[email protected]>
x11appjail is a specialized tool for creating, verifying, installing, and running AppJails. An AppJail is a CLI, TUI or X11 application that runs inside a FreeBSD jail but is perceived by the end user as identical (or at least very similar) to an application running directly on the host system.
This tool makes extensive use of appjail(1) as its engine; however, unlike the latter, the primary user in x11appjail is neither root nor a privileged user, but rather an unprivileged user. The fundamental goal of this project is to grant the user limited access to the jail, restricted solely to the execution of a CLI, TUI or X11 application.
This project began months ago as a prototype to establish a workflow leveraging appjail-x11(1); however, starting with version 1.0.0, it was rewritten from scratch into a unified tool that integrates all its projects, such as sysutils/appjail, sysutils/unixexec, archivers/appscript, and sysutils/jtransfer, among others. Even better, it allows for the execution of not only X11 applications but also CLI and TUI programs.
The most relevant project for x11appjail(1) is not only appjail(1), but also appscript(1). My goal with appscript(1) is to create an ultra-lightweight alternative to AppImage for FreeBSD that does not depend on FUSE, thus eliminating the need to configure vfs.usermount=1. appscript(1) allows you to create an elf(5) executable that contains everything necessary to run a self-contained executable.
The most significant changes and improvements for appscript(1) and x11appjail(1) are:
- Executables created by appscript(1) extract the payload cooperatively: the leader process extracts the payload once using an exclusive lock, while other processes (if any) wait using a shared lock. Unlike previous versions, where the payload was extracted to a random directory upon every execution, this significantly improves performance by extracting the payload only once; furthermore, the resulting directory is removed by the last remaining process once no running processes remain.
- appscript-verify(1) is a new command installed by archivers/appscript to verify executables signed with signify(1); it is particularly relevant to x11appjail(1)'s veriexec (see below).
- x11appjail(1)'s veriexec is an internal tool used by x11appjail(1) to run an AppJail in portable mode only if it is signed with a trusted key. This tool is unrelated to NetBSD’s veriexec.
- Both tools support the classic, battle-tested SHA-256 algorithm and the faster yet secure BLAKE3 algorithm. When sysutils/b3sum is available (the default if x11appjail(1) was installed from ports), BLAKE3 is the default choice, unless SHA-256 is explicitly specified in rc.conf(5). The checksum algorithm is fundamental to both x11appjail(1) and appscript(1). In the case of x11appjail(1), the algorithm is used in internal operations such as veriexec, whereas appscript(1) uses it to verify executables. BLAKE3 has been selected as the default option because it offers greater speed without compromising security.
Both tools support the classic, battle-tested SHA-256 algorithm and the faster yet secure BLAKE3 algorithm. When sysutils/b3sum is available (the default if x11appjail(1) was installed from ports), BLAKE3 is the default choice, unless SHA-256 is explicitly specified in rc.conf(5).
The checksum algorithm is fundamental to both x11appjail(1) and appscript(1). In the case of x11appjail(1), the algorithm is used in internal operations such as veriexec, whereas appscript(1) uses it to verify executables. BLAKE3 has been selected as the default option because it offers greater speed without compromising security.
- Attributes have been implemented in x11appjail(1) as a means for both the user and the system operator to manipulate the behavior of an AppJail. For example, a system operator can create the system attribute users.uid.perms, the content of which might be "enable_3d sound usb webcam". An unprivileged user can create the user attributes appname:profile.allow.enable_3d and appname:profile.allow.sound. Subsequently, when executing an AppJail, devices become visible or remain hidden depending on whether the user holds the corresponding permission and has authorized those permissions for the jail being created. In this case, the hardware acceleration and sound devices will become visible, provided the AppJail has incorporated the necessary logic to make them visible.
Another notable change worth mentioning for x11appjail(1) are the examples added in ${EXAMPLESDIR}/Apps: badwolf, chromium, evince, feh, firefox, htop, linux-brave, mpv, nanonote, telegram-desktop and thunderbird. Beyond the applications themselves, the key factor is the deployment method. htop is an example of a CLI application, linux-brave is a Linux application, and the others are X11 applications. Web browsers, Mpv, and Thunderbird are the most interesting examples, as they demonstrate how an AppJail can use VirtualGL to properly enable hardware acceleration within a FreeBSD jail, something that would not normally be possible given that Xephyr is the backend used by appjail-x11(1). Best of all, from the end-user’s perspective, all of this is transparent.
Demo video: https://youtu.be/EBSMHBC0Phc
Sponsor: https://www.patreon.com/appjail
Port of rdma-core project to FreeBSD
Links: link: The commit series of the port URL: https://github.com/linux-rdma/rdma-core/pull/1778 link: LinuxAPI project URL: https://github.com/freebsd/linuxapi
Contact: Konstantin Belousov <[email protected]> Contact: Ariel Ehrenberg <[email protected]> Contact: Slava Shwartsman <[email protected]> Contact: Gleb Popov <[email protected]>
The Remote Direct Memory Access (RDMA) infrastructure provides high-performance interconnect between computing and storage nodes. It can operate over different physical networks, for instance Ethernet and Infiniband.
The implementation of the RDMA stack consists of several components. There is the core kernel infrastructure, and drivers for Host Channel Adapters (HCAs), providing access to the kernel verbs. Userspace applications never interact with the kernel devices directly, the core libibverbs library and vendor-specific userspace drivers provide unified and device-specific verbs.
Since RDMA intent of providing low-latency low-overhead operations, performant HCAs offload a lot of operations from CPU. Also, typical in-line operations like send and receive can be initiated and completed in userspace, where kernel only assists in the connection establishment and teardown. Due to this, the userspace RDMA software stack is crucial for its operations.
FreeBSD base system includes port of the so called OFED kernel core component, kernel drivers, as well as userspace core (libibverbs) and userspace drivers, for instance libmlx5 for managing Nvidia Connect-X4 and later HCAs. Over time, the kernel parts get some significant updates from the infiniband code in the Linux kernel, which become the home for updated OFED. Userspace part of OFED was converted into the rdma-core userspace project, that only supports Linux (and glibc). Since userspace drivers in rdma-core provide essential functionality, and since FreeBSD userspace RDMA components are quite outdated, the situation overall needs a resolution.
We attempted to update the in-tree userspace components by importing the series of rdma-core commits with dependencies, but it quickly proved to be not feasible. Instead we started looking at what it would take to make rdma-core compile and run on FreeBSD.
First, there were a number of missing glibc-specific APIs that were used in rdma-core, for instance, strdupa() and friends, main:tdestroy(3), some pthread functions. These were easy to handle in the base system, and addition of them benefited the whole FreeBSD porting story.
Next, and more serious, the unportable features of glibc were used everywhere in the sources, and trying to cover them all would cause huge porting patch, which is problematic to push upstream, even for cooperating upstream. Instead, the idea of using an approach similar to LinuxKPI for kernel code, was formed and developed, called LinuxAPI. Unlike LinuxKPI, which handles architectural mismatches between Linux kernel and FreeBSD kernel, in addition to the different C interfaces, LinuxAPI needs to smooth out the differences around extensions to the same core functionality defined by POSIX. It is mostly about bits that are not defined by POSIX but needed for RDMA to function, like networking interface enumeration, or discovery of the rdma-capable devices and their capabilities etc.
It seems that people consider the LinuxAPI useful outside the rdma-core porting efforts already, there is a project github.com/freebsd/linuxapi which takes the developed set of headers and extends it further. We are currently working on providing the permissive license to make the library useful without additional strings attached.
Our initial goal, also limited by the available hardware, is to have rdma-core work with the ConnectX-4 cards. Of course we welcome all vendors interested in RDMA on FreeBSD to improve the port to properly support their cards.
The result of the porting is available as the repository. Also we try to upstream the changes so that FreeBSD would become the second natively supported platform for rdma-core. The Pull Request to the github project is submitted. There is currently a blocking discussion about the way to organize CI for FreeBSD platform. Gleb Popov created the net/rdma-core port from the forked sources, which is already in the ports tree.
The kernel changes to get the port working were surprisingly small and contained. They mostly consisted of bug fixes for the code paths not previously exercised by userspace since there were no userspace. Most interesting part was perhaps the difference in ioctl(2) behavior between Linux and FreeBSD, where Linux can both return an error and copyout the data structure. The issue was already observed in the LinuxKPI, and the porting work provided the generic solution there.
Sponsor: Nvidia networking
NFS over Remote Direct Memory Access (RDMA)
Links: Up-to-date NFS server sources in branch freebsd-rdma URL: https://github.com/viniciusferrao/freebsd-src.git nfs-over-rdma-setup.txt URL: https://people.freebsd.org/~rmacklem/nfs-over-rdma-setup.txt
Contact: Rick Macklem <[email protected]>, Vinicius Ferrao <[email protected]>
Currently FreeBSD’s NFS is supported over TCP (and UDP for NFSv3). This project adds support for NFS over RDMA, as described by RFC-8166 and RFC-8267. This should allow RDMA aware NICs to offload most of the network transport and improve performance over fast LAN fabrics.
Thanks to Vinicius, a lot of progress has been made. He has the NFS server side working, and quite well from what I know.
The client side is now testing quite well against Vinicius’s server and both client and server are now ready for third party testing. To test, a client and server with Mellanox ConnectX4→6 NICs running a kernel built from recent FreeBSD main sources is needed.
See nfs-over-rdma-setup.txt for information on setting up a testing environment.
A stable/15 kernel should be sufficient for the loadable modules in a few weeks. The client code should also be committed to FreeBSD’s main in a few weeks, with an MFC to stable/15 be the end of 2026. The server code was created via generative AI and the FreeBSD project is working on a policy for handling generative AI submissions. In the meantime, the server code will be available as an "unofficial port" that builds a kernel loadable module.
Third party testing would be appreciated.
Thanks go to Vinicius for the NFS server work and to the FreeBSD Netperf cluster folk, without which I would have never gotten this code tested.
Sponsor for the NFS server code: Verastus HPC
nfsdtop(8) shows who is using the NFS server
Links: D59438 URL: https://reviews.freebsd.org/D59438 rG60c7313074b9 URL: https://cgit.freebsd.org/src/commit/?id=60c7313074b93adf4ea70ff44b78b3b4fc15c29f
Contact: Devin Teske <[email protected]>
nfsstat(1) reports the server as a whole. nfsdtop(8) reports the user, the group, or the client behind the reads and writes. It is a top-like display, taken with dtrace(1) from the nfsd(8) paths nfsrvd_read, nfsvno_read, nfsrvd_write, and nfsvno_write.
The default view is per user. -g coalesces by group, and -c by IPv4 client. Each interval prints a total, then the rows that did the I/O, sorted by combined read and write volume. The default interval is two seconds. The columns are humanized bandwidth unless -b asks for the bytes moved in that interval. WRITE(IN) is data the clients sent. READ(OUT) is data the server sent.
nfsdtop
nfsdtop -c
nfsdtop -g -G wheel
A UID, GID, or client address on those paths belongs to the client, not to the server. nfsdtop(8) does not ask getent(1) to name them while it samples. Names come from map files in the current directory: .nfsd.passwd, .nfsd.group, and .nfsd.hosts. A filter (-U, -G, or -C) is resolved once, from those maps and then with getent(1) or host(1), and the result is compiled into the dtrace(1) predicate.
-j emits one JSON object for the view total and one per key, each interval, with the byte counts and the rates. -J samples the client, group, and user views together:
nfsdtop -J -N 1
Only root, or a user who can run dtrace(1), can run it. The client view and -C are IPv4 only. -R, or a non-empty NFSDTOP_REDACT, replaces names that are not well-known system accounts with random strings of the same length.
The introduction is in HEAD as of 60c7313074b9 (D59438), and nfsdtop(8) makes its first release in FreeBSD 16.0.
Thanks to Alexander Ziaee and Benedict Reuschling for the man page, to Adrian Chadd for review, and to Rick Macklem for a look at the NFS side.
Run it on a server that is already busy. If the row you need is not a user, a group, or a client, please write.
Enhancing Zoned Storage support
Links: GSoC project Wiki page URL: https://wiki.freebsd.org/SummerOfCode2026Projects/EnhancingZonedStorageSupportOnFreeBSD
Contact: voidanix <[email protected]>
Project Overview
Work on this project intends to enhance Zoned Storage support in FreeBSD, by adding the following new features:
- New gzoned(8) GEOM driver for emulating zoned devices.
- Zoned Namespaces (ZNS) support for zoned NVMe drives.
- Improved Zoned Storage handling for gconcat(8), glabel(8), and gpart(8).
The work was carried out as part of Google Summer of Code 2026.
Importance to FreeBSD
The new gzoned(8) driver emulates Zoned Storage on top of regular, non-zoned drives, allowing for development, testing, and integration of Zoned Storage without zoned hardware.
ZNS support enables using Zoned Storage on NVMe SSDs.
Zone-aware GEOM classes let host-managed drives be used with the usual storage tools.
Status
gzoned(8) is now in main.
ZNS support was added to the nda(4) driver, while nvd(4) support is not planned due to its barebones nature.
Host-managed devices can now be concatenated through gconcat(8), while glabel(8) will cleanly refuse them for automatic labeling due to its metadata requirement. gpart(8) can now create GPT partition schemes on host-managed drives by not writing the backup GPT table.
Plans for next quarter
- Polish up gconcat(8), glabel(8), and ZNS support, as they can now rely on gzoned(8) from main.
- Merge the complete work into main.
Mentors: Robert Clausecker, Alan Somers, and Ken Merry Sponsor: Google Summer of Code 2026
LLDB Improvement on FreeBSD
Contact: Minsoo Choo <[email protected]>
I was off for university from May to August and I am back to working on this now. Since I could not accomplish this task for LLVM 23, the target release for completion has changed to LLVM 24.
armv7 and powerpc64be are support candidates now. Once LLDB refactoring is done, I will implement support for those architectures.
Unlike KGDB that uses custom frame sniffer for trapframe unwinding, LLDB uses DWARF CFI instead. DWARF CFI works on KGDB as well; when a frame is not recognized by KGDB’s frame sniffer, it will fall back to CFI. Thus, no change on the KGDB side is needed.
Sponsor: The FreeBSD Foundation
Procdesc: debugging API
Contact: Konstantin Belousov <[email protected]>
The process descriptors API enhancements project continued, with the goal to allow complete process control using descriptors, in particular, debugging. I wanted to make it possible to stop reference pids as the process identifiers. The milestone for it should be a demonstration of enabling the capsicum mode for some non-trivial debugger, I selected truss(1) because it does not need neither filesystem nor network namespace accesses after attached to the target.
The semi-obvious solution there is to introduce pdptrace(2), which is equivalent to ptrace(2) but takes the process descriptor as the process designator. We need to be able to obtain the notifications of the process debugging events, which are provided by waitpid[2] syscall family for pid-based controls. And, we need a way to obtain the process descriptor for a new child forked from the debuggee, to continue tracing of all descendants.
Previously, the pdopenpid(2) system call was added, which allows to get a handle on an arbitrary process. Existing operations on the process descriptors are somewhat limited: handle owner can wait for the exit notification using kqueue(2), and with some luck retrieve the process exit status.
The last point requires some elaboration. Since the pdwait(2) call was added recently, there were some amount of hacks in the kernel to allow waitpid(2) calls on pid’s of processes created with pdfork(2). As result, the waitpid(2) caller might have reaped the process before owner of the process descriptor could call pdwait(2). Similarly, if there is more than one process descriptor opened on the same process, only the first pdwait(2) caller could retrieve the exit status with pdwait(2), making other descriptors useless.
The listed set of problems also made it very hard to correctly use the proposed pdptrace(2). The process being debugged could steal events from process descriptors and vice versa. Simply disallowing wait(2) on processes with the opened descriptors is not an option for two reasons: backward compatibility, waitpid(2) was already allowed and existing binaries relied on it if the debuggee used fork(2) to create a child, it expects to get the exit notification (e.g. SIGCHLD) and exit status from wait(2)
The solution was manyfold. First, we have to postpone reaping if there are either opened process descriptors, or if the process was created with fork(2), we should not reap until wait(2) is called on pid by the parent. Second, the exit status needs to be preserved in the process descriptors private data even after reaping, to allow pdwait(2) on any of the descriptors. This was implemented by providing a bitmap of the 'zombie refs' on the kernel struct proc. Each zombie reference prevents reaping, and cleared by corresponding call to waitpid(2) or pdwait(2). Only when all registered references are cleared, zombie can be reaped. If the process is created with pdfork(2) or opened with pdopenpid[2], it gets the procdesc zombie reference. If the process was created with fork(2), it gets the 'parent' zombie reference. By default, pdfork[2] also sets the parent reference to allow the waitpid(2), for compatibility. The new pdfork(2) flag PD_NOWAITPID prevents that.
Then, wait-like events must work with the process descriptors. The procdesc kqueue(2) event filter was extended with NOTE_PDSIGCHLD hints to report that pdwait(2) can retrieve tracing or exiting event on the descriptor.
Then, the pdptrace(2) was able to usefully control the target. A new ptrace call to retrieve the list of the attached processes PT_GET_CHILDREN allowed pdptrace(2) to get hold of forks.
With all the features implemented, it was possible to convert truss(1) to use only process descriptors to control the traced processes. The existing mode of using pids was preserved, and can be selected with the '-y' option as an emergency switch and to easy comparison and debugging of the new mode.
Sponsor: The FreeBSD Foundation