Mark your calendars! The November 2023 FreeBSD Vendor Summit will take place November 2-3, 2023 at the NetApp Campus in San Jose, CA. The Vendor Summit will feature a single track of talks on both days. 

More details on the schedule and travel information will be available soon. In the meantime we are asking for your talk proposals now.  Talks should be technical in nature and aim for 30-35 minutes in length with an additional 10-15 minutes available for Q&A and will be given in person.  Proposals for talks should include a brief abstract of the topic as well as a brief bio of the speaker(s).  If you need more or less time, please include that detail in your proposal.  Please submit talk proposals to devsummit@FreeBSD.org by September 26, 2023.

If you have any questions, please feel free to contact the organizers via the email above. Thank you to NetApp for hosting the summit.

Long before breakthrough innovations hit VC pitch decks, let alone your laptop, microservice, or smartphone, they typically start as a hypothesis in a University or industrial research lab. 

Take Docker, for example. This building block of microservices and agile methodologies stands on the shoulders of the virtualization and system partitioning innovation in FreeBSD called Jails. And Jails, you may have guessed, emerged from research undertaken by Robert Watson and Poul-Henning Kamp. 

After his work on Jails, Professor Watson joined the Department of Computer Science at the University of Cambridge in the UK, where he continues to research and develop breakthrough ways to improve computer system security. His work earned him the EuroSys Jochen Liedtke Young Researcher Award, granted annually to European early researchers (i.e., those no more than 10 years on from receiving their PhD) who have demonstrated exceptional creativity and innovation in systems research. 

In selecting Professor Watson, EuroSys noted his long history of contributions in systems research, including co-developing the Jail security model that is an intellectual foundation for contemporary OS containerization; leading development of the kernel access-control framework used for application sandboxing in systems from macOS and Junos to FreeBSD; developing the Capsicum OS security model, and most recently leading developing of the CHERI computer architecture. CHERI is now the key technology being explored in the UK Industrial Strategy Challenge Fund (ISCF) £187M (roughly $225M) Digital Security by Design (DSbD) program. 

CHERI (Capability Hardware Enhanced RISC instructions) is an architectural feature that enables fine-grained C/C++ memory safety and scalable software compartmentalisation, and was developed by SRI International and the University of Cambridge starting in 2010.

In order to make CHERI available to write and run programs on, it requires a development board. This is where Morello comes in. Arm’s Morello is a processor design, System-on-Chip (SoC), and board that integrates support for the CHERI protection model. The Morello development board, compiler, and toolchain allow researchers and industry practitioners to write and run programs leveraging CHERI. AutoCHERI, for example, is testing CHERI and Morello as a hyper-secure architecture for in-vehicle Telematics Control Units.

Professor Watson was kind enough to sit with the FreeBSD Foundation to discuss his research. The discussion illuminates the role of academic research and the process by which breakthroughs in the lab make their way into our digital society. A key tool in Professor Watson’s quiver is FreeBSD. Like many other OSes, it is open source so supports the necessary customization. In contrast with Linux, the permissive BSD license is essential to supporting the public – private partnership his research relies on.   

To understand why open source in general, and FreeBSD in particular, is so central to Professor Watson’s work, and to academic computer system research more broadly, it helps to first understand the research process. Professor Watson explains “in systems research, one builds prototypes of ideas. You begin with a pure hypothesis about the way the system should work, or should not work, or perhaps how some tooling that you have come up with or a change to the design will work, something that is an intellectual contribution. You then apply it to an artifact, like an operating system or a compiler. You then evaluate it, and then you iterate it to correct for learnings about your hypotheses, undesirable outcomes, or there was a problem we did not understand, and so on. In all the work mentioned in the EuroSys award, FreeBSD has been that starting artifact.”

Groundbreaking academic research benefits enormously from a production system against which to test hypotheses and into which the innovations can be later transitioned. “Open source is essential to this research approach in the software space, and increasingly in the hardware space,” Dr. Watson explains. “You could build the reference baseline artifact yourself, but what you really want is something that is the current state of the art, that has the complexity that comes from large scale use, and so on. FreeBSD meets these criteria.”

To those familiar with the history of FreeBSD, it may come as no surprise that Professor Watson uses it so heavily at Cambridge. FreeBSD has a rich history in the academic community. It was derived from the 4.4-Lite version of the Berkeley Software Distribution developed by the Computer Systems Research Group at the University of California at Berkeley between the mid 1970s and 1990s. Over the last 30 years, the FreeBSD operating system has continued to provide those in academia a stable base on which to undertake research, and a path to industrial adoption via widely used products and services that run on, are based on, or incorporate, FreeBSD ¹

Professor Watson’s Mandatory Access Control (MAC) framework research continued along the lines from Jails, arguing that your OS should have pluggable components to allow it to work with many different pieces of hardware, and that access control and security should also be pluggable. 

Many users customize FreeBSD in their products—adding things like device drivers and file systems—this is often called localizing. Professor Watson’s MAC research argued that you could localize the operating systems and the security requirements of your product. This provides extensibility so that companies building a router or mobile phone operating system or some other appliance with FreeBSD can tune the OS to the environment they need in terms of security, in addition to hardware, storage, and network tuning. 

In terms of how this research transitioned to popular use, Professor Watson feels it was quite a successful piece of research (we’d call that an understatement). The research targeted FreeBSD and was incorporated into other systems, most notably iOS. 

CHERI, which stands for Capability Hardware Enhanced RISC Instructions, extends conventional processor Instruction-Set Architectures (ISAs) with architectural capabilities to enable fine-grained memory protection and highly scalable software compartmentalization. The Capsicum work took some ideas from the 1970s called capability systems, and argued that they can be made current by atoms-smashing with a current piece of software through BSD. The CHERI work takes this concept much further and applies it to processors. “With CHERI, we changed the hardware and we changed the software. And the software we chose to change to demonstrate these ideas, but also understand them, is FreeBSD,” remarked Professor Watson.

CHERI looks at hardware/software co-design, which requires coordinated changes to the software and the hardware. The interface between the two is the instruction set architecture, or ISA. A new ISA enables processor advancements to be expressed by software. So hardware/software co-design requires changes to both the hardware and the software.² 

At BSDCan 2023, Brooks Davis from SRI International explained that “CHERI mitigates vulnerabilities in C/C++ Trusted Computing Bases, such as hypervisors, operating systems, language runtimes, browsers, ….” CHERI is proving to be extremely effective. The Microsoft Security Response Center (MSRC) found that CHERI mitigates over two thirds of critical memory-safety security vulnerabilities in C/C++-language software.³

FreeBSD is essential to this kind of research thanks in part to the permissive BSD license that supports the modification of the entire hardware-software stack, and because of the comprehensive integration of LLVM to build a full kernel and user space. When the project began in 2010, FreeBSD was aggressively pursuing LLVM integration, which continues to be a challenge for Linux today. Also important were clean kernel support for multiple ABIs, integration of the Capsicum security model, and strong early support for the RISC-V architecture. 

The CHERI team has contributed back to FreeBSD extensively during this work, improving FreeBSD’s 64-bit MIPS and Armv8-A support, contributing a RISC-V port, adding numerous device drivers to better support Xilinx and Intel FPGA boards, as well as Arm IP, and developing QMEU userlevel and cross-build support for the base system and ports/packages.

Interested users can download a full FreeBSD-derived OS called CheriBSD. CheriBSD is a research operating system that makes extensive use of CHERI to improve software security – and demonstrates an incremental software adoption path for CHERI. Its features include a memory-safe kernel and userspace, support for two software compartmentalisation models, and roughly ten thousand memory-safe third-party packages including server applications such as nginx, a KDE Plasma desktop environment. Later this year, a memory-safe Chromium web browser, sponsored by Google and InnovateUK, will be added to the CheriBSD package collection. It can be installed on Arm Morello systems using a downloadable USB stick image. CheriBSD has an active user community of over 70 companies and universities that have Morello-based research projects, with almost all running CheriBSD, and its most active contributors are SRI, Cambridge, and Microsoft.

There is a build system that cross builds CheriBSD from Linux, Mac, or FreeBSD. Professor Watson and the others working on CHERI have actively contributed Linux and macOS cross-build support back to FreeBSD. This is important, Professor Watson argues, “because we think to make FreeBSD and our work really accessible, we can’t tell you what to run on your desktop. You have to run your OS of choice, and we help you get FreeBSD running on whatever device you want it to run on, which might be the desktop, but, it might also be an embedded device, or it might be a server somewhere, and we don’t want any obstacles standing in the way of that.”

As mentioned, the Morello processor design, System-on-Chip (SoC), and board integrate support for the CHERI protection model. Morello is a research prototype jointly funded by Arm and UK Research and Innovation (UKRI), and created in collaboration between Arm and Cambridge to evaluate CHERI as a technology for mainstream adoption. Over 600 boards have been shipped since mid-2022, primarily to universities, government labs, and industrial research laboratories. The FreeBSD Foundation will receive its first Morello board later in 2023, making this development environment available to the global FreeBSD community.

To get hands on with CHERI, go to the CHERI software distribution site and grab the latest release. Docker images are available for Linux and other OSes. The images include environments that allow users to run a QEMU-based VM with CheriBSD for the CHERI-RISC-V or Arm Morello architecture, and cross-compile software for it using the included SDK. For Arm Morello, use an image from: https://hub.docker.com/r/ctsrd/cheribsd-sdk-qemu-morello-purecap and once a Docker container is up, a single command starts CheriBSD⁴. How academic innovations transition from the lab to production

Transition for research can take many forms. In some cases, people and companies use the software. Sometimes, transition means that the ideas influence other people’s work, and then eventually that ends up somewhere. 

“For something like the MAC framework, or Jails, it’s quite easy to look out there and see all the use cases, it’s used in all kinds of things. For something like CHERI, we’re not yet at the point where we could really speak to what the ultimate transition will be, but there is a big transition project going on. The UK Government and various companies are spending about a quarter of a billion dollars on a five-year transition project currently, which is quite exciting.”

The CHERI work has a number of transition narratives. CHERI was originally done relative to the MIPS architecture when it began in about 2010. Now, all of the work is on Arm and RISC-V. RISC-V is the open source research platform, Arm is the current transition target of choice, although Professor Watson quickly adds that he and the others would be happy to transition to other hardware also. “Network routers and switches, firewalls, phones, tablets, were all the ambition, really. I think it’s quite possible to imagine well beyond that, servers and desktops are all in scope too, but that was what we were doing in early demonstrations.”

On behalf of all the computer users who have benefitted from his and his partners’ security research, the FreeBSD Foundation expresses its gratitude to Professor Watson. Far from ivory tower pursuits, these innovations undergird much of contemporary society’s digital infrastructure. As a completely open source project, we hope you will consider getting involved with FreeBSD and helping write the next chapter in computing. 

— Contributed by Greg Wallace

There are different ways to measure how work on FreeBSD is progressing such as the rate of commits, the number of developers, the number of FreeBSD ports, and so on. By one measure, the number of Foundation-funded projects, we are in a boom cycle. As of the time of writing, the FreeBSD Foundation has contracts open for 12 different projects. Some projects we have written about in past newsletters, others have only begun recently. What follows is a summary of this contracted work as well as some noteworthy development by Foundation employees. 

Contracted Work 

Documentation and Testing Internship 

Starting in July, Yan-Hao Wang began a summer internship with the Foundation to work on a variety of tasks. To start, Yan-Hao will focus on improving our documentation tooling. One deliverable is to build an online editor designed solely to make creating and editing man pages as simple as possible. A second is to develop an “expert system” for FreeBSD man pages and other documentation. This best-effort and proof-of-concept deliverable will involve importing FreeBSD documents such as man pages and the Handbooks into a vector database so that large language models like ChatGPT can “read” them in order to offer better answers when queried with FreeBSD questions. Making improvements to our testing framework is a second general goal of the summer’s work. For example, Yan-Hao will add missing tests for many of the userland tools under /bin, /sbin, /usr/bin, and /usr/sbin as well as libxo. Finally, some miscellaneous deliverables include updating the FreeBSD Jenkins tinderbox and developing a support roadmap for RPI4 support. 

Addressing OpenSSL 3 / LLVM 16 Ports Fallout 

A major obstacle to releasing FreeBSD 14.0, one that delayed the original release schedule, was the version of OpenSSL in the base system. With the end-of-life for OpenSSL 1.1.1 planned for September 2023, it was imperative to move to OpenSSL 3 prior to the release. Foundation team member Pierre Pronchery along with other members of the FreeBSD development community have mostly completed the update, however lots of code in both the base system and the ports tree that depend on OpenSSL require fixes to work with this new major version. Around the same time OpenSSL was updated in the base system, LLVM was updated to version 16, which also introduced some breaking changes, especially in the ports tree. Most of the critical issues with OpenSSL 3 and LLVM 15 have already been fixed, but with LLVM 16 there are approximately 800 additional ports that fail to build resulting in an additional 2800 dependent ports that are skipped in a full ports tree build. Muhammad Moinur (Moin) Rahman will complete the time-consuming and tedious work to fix all port issues related to the update to OpenSSL 3 and LLVM 16. 

SIMD-enhanced libc for amd64 

Modern computer architectures provide SIMD (single instruction multiple data) instruction set extensions to operate on multiple data at once. 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), to speed up most C programs. 

Commonly used for numerical applications such as video codecs, graphics rendering, and scientific computing, use of SIMD techniques also aids in basic data processing tasks such as those implemented by libc functions. While other libc implementations already provide SIMD enhanced variants of standard libc functions, the FreeBSD libc largely does not. The objective of this project by Robert Clausecker is to provide such SIMD-enhanced versions of relevant libc library functions and thus improve the performance of software linked against it. As these libc functions are used by most software available for FreeBSD, these enhancements are projected to give a broad benefit for a wide range of programs. The primary focus of the project is amd64 with the aim to produce SIMD optimised implementations based on the architecture levels defined by the x86_64 psABI. 

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

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. 

Networking Summer Internship 

Naman Sood is a FreeBSD Foundation summer intern who has been working on networking related tasks such as (1) completing work started by Luiz Amaral to allow pfsync traffic to be carried over IPv6 and (2) updating work to implement RFC 4787 REQs 1 and 3 for pf full cone NAT. Naman has also fixed bugs in pw(8) and du(1) and has begun to explore completing tcp checkpoint and failover work started by Klaus P. Ohrhallinger. 

Security Sandboxing Using ktrace(1) 

Starting in June, Jake Freeland began an internship with the Foundation to work on Capsicum-related projects. Capsicum was built to limit the capabilities given to applications and libraries. The core idea is intuitive; once capability mode is entered, resource acquisition and external communication is limited. It is fairly easy to design a program around this principle, but problems arise when applications that were not designed to be sandboxed need to work in this environment. It can be difficult to determine which actions cause Capsicum violations and it is impossible to pre-open resources that have not been requested or named yet. Furthermore, the developer needs to be fully acquainted with the program before they can begin to implement Capsicum functionality. Due to these challenges, progress and development surrounding the framework has waned in recent years. 

The internship will involve working on a number of projects that, as a whole, aim to revitalize Capsicum. The primary goal is to enhance and ease the experience for developers who wish to Capsicumize their existing programs. The biggest enemy of Capsicum is its large learning curve. Refactoring a program to support capability mode often requires the developer to know what causes Capsicum violations and know how to restructure the given program to avoid violations. Sometimes this process is trivial, but larger programs often need resources on-demand and figuring out how to serve these needs can be difficult. Extending the number of tools available to the developer for convenient program Capsicumization will decrease the learning curve. If Capsicumization is easy, then more developers will adopt it. 

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), which logs kernel activity for a specified process. While ktrace can record and return extra information about your program’s violations, this can be inconvenient because ktrace only reports the first capability violation before the program terminates. 

A new ktrace extension written by Jake can record violations when a program is not in capability mode. This means capability violation tracing can be run on an unmodified program and since the program is not required to be run in capability mode, it will still acquire resources and execute normally even when capability violations occur. 

Upon completion of the ktrace extension Jake will begin to capsicumize various utilities, including syslogd(8), NFS daemons, ggatec(8)/ggated(8), tftpd(8), ntpd(8), and libarchive(8). 

Wireless Internship 

En-Wei Wu, a 2022 Google Summer of Code Contributor, began an internship with the FreeBSD Foundation in early 2023 to work on FreeBSD wireless drivers and tools. The work is divided into three components. 

Continuous Integration Enhancements 

FreeBSD’s Jenkins-based CI infrastructure currently initiates a job every time a developer pushes a commit to the FreeBSD src repository. While this is valuable for identifying newly introduced problems, it would be even better to easily identify these issues before they are pushed to the main branch. This goal can be achieved by making CI tests more accessible to developers in a pre-commit environment and also by having private FreeBSD runners that the popular git hosting services could leverage to create CI infrastructure for people pushing to private branches. To that end, Muhammad Moinur Rahman aims to take CI scripts written by Li-Wen Hsu and make them available to developers as part of the build system. Similar to how make universe or make tinderbox builds all supported architectures, make ci would achieve something similar for all the supported builds. A parallel goal is to make it possible for developers to run individual CI jobs when debugging problems. The hope is that this flexibility will also allow for others to integrate these builds / scripts into other CI tools like Cirrus CI that are run from Github. 

Improving the kinst DTrace provider 

DTrace is a framework that gives administrators and kernel developers the ability to observe kernel behavior in real time. DTrace has kernel modules called “providers”, which perform a particular instrumentation in the kernel using “probes”. kinst is a new DTrace provider created by Christos Margiolis and Mark Johnston as part of GSOC 2022 that allows for instruction-level tracing, that is, for a given kernel function, a user can trace each instruction in it. The provider is available in FreeBSD 14.0. 

kinst probes take the form of kinst::<function>:<offset>, where <function> is the kernel function to be traced, and <offset> is the specific instruction. The offsets can be obtained from the function’s disassembly using kgdb(1). For example, the following command will trace vm_fault()’s first instruction each time it executes: 

This project, which was completed in late July, implemented inline function tracing. In order to achieve this functionality, the DWARF debugging standard was used to be able to detect inline calls and handle them accordingly. DWARF’s and kinst’s functionality were leveraged to address some of the shortcomings of FBT, such as the tail-call optimization problem (chapter 20.4 of the DTrace manual) and the absence of inline tracing capabilities. 

Project deliverables included: 

FreeBSD as a Tier I cloud-init Platform 

cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init’s support for operating systems other than Linux is 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 I platform. To remedy this, the FreeBSD Foundation has contracted Mina Galić to bring FreeBSD cloud-init support on par with Linux support. The project deliverables include completing an extraction of certain networking classes, implementing ifconfig(8) and login.conf(5) parsers, implementing IPv6 configuration, creating devd rules for Azure, and writing Handbook documentation about productionizing FreeBSD. 

A number of project milestones were completed in the last quarter: 

These are used by several cloud providers to initialize a temporary network before retrieving the actual configuration. 

The hope is that with the next cloud-init release, Vultr can be convinced to switch their FreeBSD images to cloud-init. 

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, shaving off a few more milliseconds from the boot time. 

The next steps will be to continue work on 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. 

OpenStack on FreeBSD 

OpenStack is an open-source cloud operating system for many kinds of resources, from virtual machines, containers, to bare-metal servers. OpenStack’s control plane mainly targets Linux and FreeBSD is only unofficially supported as a guest operating system. Users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible for administrators or operators to set up OpenStack deployments running on FreeBSD hosts. Given the increasingly important role of cloud-based deployments, and the popularity of OpenStack with various cloud providers, the FreeBSD Foundation has contracted Chin-Hsin Chang to port OpenStack components, so the system as a whole can be run on FreeBSD hosts. 

The Linux-based OpenStack components to be ported to FreeBSD/amd64 include, but are not limited to: 

As of the second quarter of 2023, some key achievements include: 

Work has begun to port nova-novncproxy and nova-serialproxy, which will increase the ways the instance console can be accessed. To lower the threshold for those who want to test the work, the development environment has also been migrated from a physical to a virtual instance. Anyone interested in testing should be aware that there is still a problem running bhyve VMs on top of Linux KVM. A detailed write-up of the issue can be found at https://hackmd.io/@starbops/SkdJON2un. Other work planned for the near future includes improving the console proxy services to make the overall workflow more fluent. Step-by-step documents for constructing a proof-of-concept site can be found at https://github.com/openstack-on-freebsd/docs. The patched version of each OpenStack component is under the same GitHub organization. 

Snapshots on Filesystems Using Journaled Soft Updates 

The UFS/FFS filesystem has the ability to take snapshots. Because the ability to take snapshots was added after soft updates were written, they were fully integrated with soft updates. However, when journaled soft updates were added in 2010, they were never integrated with snapshots. So, snapshots cannot be used on filesystems running with journaled soft updates. There are two instances where UFS snapshots are still important. First, they allow reliable dumps of live filesystems, which avoids possibly hours of down time. Second, they allow running background fsck. Similar to the need for scrub in ZFS, fsck needs to be run periodically to find undetected disk failures. Snapshots allow fsck to be run on live filesystems rather than needing to schedule down time. This work requires extensive changes in the UFS/FFS soft updates and snapshot kernel code and also in the fsck_ffs utility. 

The work is divided between two milestones. Milestone 1, which was completed in late 2022 enables snapshots when running with journaled soft updates. These snapshots are usable for doing background dumps on a live filesystem. Milestone 2 involves extending fsck_ffs to be able to do a background check using a snapshot on a filesystem running with journaled soft updates. As of mid-August, the changes that are needed in the kernel and fsck_ffs are complete and testing has gone smoothly. 

Related to this project, Kirk has been working on a number of filesystem panics that were recently reported as well as a few older UFS bugs. These included bugs that could trigger false corruption warnings in the UFS superblock integrity checks. All the fixes were tested in time for inclusion in FreeBSD 14 and those relevant to FreeBSD 13 were MFCed. 

WiFi 

The FreeBSD WiFi stack needs ongoing maintenance and development to keep up with new standards and devices. The Foundation is funding Bjoern Zeeb to integrate support for current-generation Intel WiFi devices by migrating to the dual-licensed upstream driver from the Linux kernel.  Under the contract, Bjoern also takes on related wireless work such as development of the 802.11 LinuxKPI and integration of other wireless drivers, such as those from Realtek.

In the latest quarter nearly all of Bjoern’s time was dedicated to LinuxKPI updates in preparation for an iwlwifi(4) update as well as updates to other drivers such as rtw88, rtw89, mt76, and ath10k, as well as preparations for ath11k and ath12k.  Most of this work is already in the tree and will soon be connected to the build for people to test.

Other Foundation Work 

As we reported in our 2023 Q2 status report entry, 339 src, 155 ports, and 20 doc tree commits identified the FreeBSD Foundation as a sponsor. A sample of this work includes: 

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. Foundation team member Pierre Pronchery spoke about driver harmony between the BSDs and En-Wei Wu discussed wtap work completed under contract with the Foundation. 

Base OpenSSL 3 Update 

As already mentioned, the pending removal of upstream support for the 1.1 branch of OpenSSL was a major obstacle to releasing FreeBSD 14.0. New Foundation team member, Pierre Pronchery, along with Ed Maste and other members of the FreeBSD developer community got to work updating our base OpenSSL to version 3. 

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 Internet’s infrastructure. 

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 a 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 Long Term Support, 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 2.000 files. Perhaps as a consequence, its build system is relatively complex and normally requires Perl, which has been removed from FreeBSD’s base system since 5.0-RELEASE. Thankfully however, it was possible to import and set up OpenSSL’s 3.0.9 release the FreeBSD way, and it is now part of the base system as planned for FreeBSD’s 14.0 release. 

It is an understatement to mention that OpenSSL 3 is a new major release. 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 away into a “legacy” module, it is also possible to restrict the implementation to 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 when writing these lines). 

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. 

Bump amd64 MAXCPU from 256 to 1024 

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. Foundation team member Ed Maste and other developers have made a number of changes 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.

FreeBSD on Microsoft HyperV and Azure 

Li-Wen Hsu, Wei Hu, and other member of the FreeBSD Azure Release Engineering Team, along with Souradeep Chakrabarti <schakrabarti@microsoft.com>, and other members of the Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com> have been working to add FreeBSD ARM64 architecture support to Azure. Part of that work has involved publishing images to the Azure community gallery. There are some testing images available in the project’s testing public gallery, named `FreeBSDCGTest-d8a43fa5-745a-4910-9f71-0c9da2ac22bf`: 

To use them, when creating a virtual machine: 

Work in progress includes: 

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

Wei Hu and Souradeep Chakrabarti from are working on several Microsoft-sponsored tasks, including: 

Open tasks: 

Google Summer of Code 

Coding for the 2023 edition of GSoC has just passed the midway point and the progress of the seven FreeBSD projects are documented on the wiki. Foundation team members are serving as our organization administrators and three projects are being mentored by people connected to the Foundation. 

CI Test Harness For Bootloader 

FreeBSD supports multiple architectures, file systems, and disk-partitioning schemes. For this project, Sudhanshu Mohan Kashyap <smk@FreeBSD.org>, is writing a Lua script to permit testing the boot loader for all these combinations for tier 1 and tier 2 architectures. If time permits, further exploration may be done to integrate the scripts into the existing build infrastructure (either Jenkins or Github Actions) to generate a comprehensive summary of the test results. 

Currently any developer changes may 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 the full make universe required today. These attributes allow developers to routinely use the script, and allow integration into the CI pipelines without undue cost. 

Physical memory compaction for the FreeBSD kernel 

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. The goal of this GSoC work 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. 

Integrate mfsBSD into the release building tools 

mfsBSD is a toolset created by Martin Matuška to create small-sized but full-featured mfsroot based distributions of FreeBSD. That is, it loads files from a storage device and stores them in memory via a memory file system (MFS). As part of this project, Soobin Rho <soobinrho@FreeBSD.org> will create 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 Working Group began because a long-time FreeBSD user, Michael Osipov, took the time to provide the Foundation with detailed notes on where he is hitting limits with FreeBSD. 

The next step was to gauge interest – I posted this call for interest on LinkedIn and on Discord and the response was great. 40 people raised their hands to join the WG. Here is the breakdown of the 40 people by their role.

A lucky 13 people, myself included, joined the first meeting of the Enterprise Working Group on August 16. Here’s the recap.

After the housekeeping, including a reminder of the FreeBSD Code of Conduct we ratified the WG charter and moved on to the list of gaps. 

In the process, we had a nice discussion in a few areas:

One of the first points of discussion had to do with the adjacent, but I think slightly different, scientific computing use case. This was great timing because literally earlier in the week I had a call with a long-time FreeBSD user and community member who is trying to improve FreeBSD in this area. After the call, I connected everyone and my Foundation colleague Joe Mingrone also added some ports maintainers working in this area. If you are interested in helping in this area, please let me know and I will connect you with the right folks. 

The next discussion had to do with shoring up Samba support. Allan Jude mentioned how Klara is working on a special Samba module to go into upstream to allow it to take advantage of the new block reference tree ZFS feature. To get more general upstream support for FreeBSD in Samba we need to get FreeBSD workers in the Samba CI system. Thenext step here is to seek volunteers from the community to work upstream on FreeBSD support. Please reach out if you can help.

One attendee commented that of all the topics, Cloud Native is the most important in their view, perhaps more important than all the others combined. Allan brought a new project to the group’s attention, called XC: https://github.com/michael-yuji/xc Others asked how this relates to runj. The Open Container Initiative community is working on FreeBSD support and some Enterprise WG participants have expressed interest in helping. THANK YOU!

A participant working at a data center server manufacturer asked about the status of Nvidia GPU drivers in FreeBSD for for AI and for HPC applications, such as  Nvidia h100/a100

People raised the following items to be added to the gaps list:

A participant asked how well SALT, Puppet, and Ansible support FreeBSD

All three are used in production and work great – Ansible and SALT seem more popular. Here are some resources:

You can check out the recording of the meeting here: FreeBSD Foundation Enterprise Working Group Meeting #1

If this is an area of interest and you’d like to help, please complete this Google Form and help make FreeBSD a better general purpose enterprise OS.

The FreeBSD Project is proud to have participated in the Google Summer of Code program since its inception in 2005. As we near the completion of the 2023 season, the Foundation asked a few of our GSoC students to share more about themselves and their experience working with the Project.

Q: Tell us a little bit about yourself and where you are in your education journey.

I’m Soobin Rho, and this will be my third year attending Augustana University, which is located in South Dakota. I’ll be graduating in 2025. I study philosophy, math, and computer science.

Born in South Korea, but raised in Dubai, I came to US a few years ago to attend college. My goal is to work in a great, mission-driven company during the day, and spend my free time doing stuff I truly care about, such as open-source projects for the environment and sustainability.

Q: Have you ever worked with Google Summer of Code before? 

No, GSoC 2023 is my first. I read about GSoC first on Hacker News. One of the comments said FreeBSD is one of the participating open-source projects. So, I applied. I chose my project from FreeBSD wiki’s GSoC project ideas list.

Q: Why did you want to work with FreeBSD? 

I tried a lot of operating systems, which I’m not going to name, and alongside with a lot of desktop environments. At the end, however, at least for now, I’ve decided that my favorite coding environment is FreeBSD with vim and tmux without any desktop environment with just the terminal.

Of course, I resort back to other operating systems from time to time whenever I need to do stuff with GUI. Nonetheless, it just feels right. I’m doing all of my dev stuff through FreeBSD. Joining GSoC 2023 was my first time contributing to FreeBSD, but I also intend to stay as a contributor and keep maintaining the mfsBSD integration.

Q: Please tell us a little about your Google Summer of Code project.

Speaking of mfsBSD, which was created in 2007 by Matuska, mfs stands for memory file system. Basically, once you install mfsBSD into a system and boot into it, all of the operating system is now running under a memory file system. What this means is that you can do a lot of stuff now, such as recovery operations and system diagnostics. Especially, my favorite use case for mfsBSD is for one of my laptops with just one drive. I can boot mfsBSD in the drive and then install FreeBSD on the exact drive that I installed mfsBSD at. Since every file in mfsBSD was moved and loaded to the memory file system, the original drive can be even deleted and overwritten with a completely new FreeBSD instance using `bsdinstall` from mfsBSD.

My project integrates mfsBSD into the FreeBSD release tool set, such that mfsBSD images (.img for disc and .iso for opticals) will now be available at the FreeBSD homepage¹.

Q: What have you learned from this experience so far? 

I didn’t know anything about MAKE(1) before taking on this project. Reading `/usr/src/Makefile` and `/usr/src/release/Makefile` helped me a lot. Also, it was extremely valuable to read `/usr/src/release/Makefile.vm`, and in fact, a lot of my code is based on these makefiles.

Q: How has working with the FreeBSD Project been?

Fun and exciting! It was fun to have a weekly meeting with my mentors, Joseph Mingrone and Juraj Lutter. It was exciting to see my code producing mfsBSD images I can use myself, as well as for a lot of others whoever needs them.

The FreeBSD Project is proud to have participated in the Google Summer of Code program since its inception in 2005. As we near the completion of the 2023 season, the Foundation asked a few of our GSoC students to share more about themselves and their experience working with the Project.

Q: Tell us a little bit about yourself and where you are in your education journey?
I am Raghav Sharma, an undergraduate student in India pursuing a Bachelor of Technology in Electronics Engineering. I am currently in my final year of B.Tech. The areas that capture my interest are systems programming, kernel development, compilers, and backend projects.

Q: Have you ever worked with Google Summer of Code before?
Yes. I worked with Google Summer of Code 2022 with the Haiku organization for porting the XFS file system driver to the HaikuOS project.

Q: Why did you want to work with FreeBSD?
The FreeBSD project is an excellent opportunity for me to delve more into systems programming and kernel development. There are lots of amazing projects where community is working and I wanted to explore those ideas.

Q: Please tell us a little about your Google Summer of Code project?
The goal of my project is to add SquashFS driver support to the FreeBSD kernel. SquashFS is the read-only file system that lets you compress whole file systems or single directories, write them to other devices/partitions or to ordinary files and then mount them directly. There exists two implementations for SquashFS one is a Linux kernel driver and the second one is a SquashFuse project. I used both of these implementations to port the driver to our FreeBSD kernel. Since we are almost at the end of Summer of Code, I finished driver implementation. We now support mount(8), directories, files, and symlinks for SquashFS.

Q: What have you learned from this experience so far?
My learning experience so far is :

Q: How has working with the FreeBSD Project been?
So far it’s very amazing. Thanks to mentor Chuck Tuffli to help me get started on everything like setting up a development environment, guiding me to necessary docs for SquashFS implementation, etc.
The community is also pretty nice and active as well.

The FreeBSD Project is proud to have participated in the Google Summer of Code program since its inception in 2005. As we near the completion of the 2023 season, the Foundation asked a few of our GSoC students to share more about themselves and their experience working with the Project.

Q: Tell us a little bit about yourself and where you are in your education journey.

My name is Sudhanshu Mohan Kashyap, and I recently completed my majors in Electrical and Electronics from BITS Goa last year. Currently, I’m working as a Junior Analyst (SE1) at JP Morgan Chase & Co. I’m passionate about Linux and FreeBSD and spend a lot of my free time tinkering with VPS boxes. I’m excited to contribute to open-source projects like FreeBSD and enhance my skills further.

Q: Have you ever worked with Google Summer of Code before?

No, this is my first time participating in the Google Summer of Code program.

Q: Why did you want to work with FreeBSD?

I was introduced to FreeBSD by a close associate who contributed to FreeBSD ports. I’ve developed a strong interest in creating websites and server administration, and I’ve gained significant knowledge by hosting Minetest servers. With a background in Electrical & Electronics and experience in Infrastructure Engineering, I see FreeBSD as a great platform to combine my skills and contribute to a renowned open-source project.

Q: Please tell us a little about your Google Summer of Code project.

My project proposal is about creating a CI test harness for the boot loader in FreeBSD. The current script, full-test.sh, lacks comprehensive testing for all supported architectures and combinations. I plan to rewrite this script in Lua, enabling testing for multiple architecture combinations and generating reports for broken combinations and expected functionality. If time allows, I’ll integrate the script with existing build infrastructure like Jenkins or Github Actions to provide comprehensive test results.

Q: What have you learned from this experience so far?

Throughout this experience, under the mentorship of Warner Losh, I’ve acquired valuable technical skills, including deploying servers, Lua programming, and modular scripting. I’ve learned the importance of meticulous project planning, effective communication in collaborative coding environments, and the significance of systematic testing. With Warner’s guidance, I’ve successfully configured servers, resolved design issues, and enhanced code quality through in-depth testing. This journey has not only expanded my technical expertise but also improved my problem-solving abilities and attention to detail, making me a more proficient and adaptable software developer.

Q: How has working with the FreeBSD Project been?

Working with the FreeBSD Project has been an enlightening experience. The feedback and guidance from mentors like Warner Losh have been instrumental in refining my project proposal. The project aligns well with my interests and skills, and I’m excited to contribute to such a renowned open-source community.

The FreeBSD Project is proud to have participated in the Google Summer of Code program since its inception in 2005. As we near the completion of the 2023 season, the Foundation asked a few of our GSoC students to share more about themselves and their experience working with the Project.

Q: Tell us a little bit about yourself and where you are in your education journey.

Hi! My name is Aymeric Wibo and I’m currently pursuing a bachelor’s degree in computer science at the University of Louvain in Louvain-la-Neuve, Belgium.

Q: Have you ever worked with Google Summer of Code before? 

Nope! First time.

Q: Why did you want to work with FreeBSD? 

I’ve been running FreeBSD as my primary OS for a bit over 2 years and I had already submitted a few patches here and there, so I thought the natural next step would be to work on something a bit more substantial for FreeBSD, especially after having briefly met some of the members of the project at FOSDEM this year.

Q: Please tell us a little about your Google Summer of Code project.

My project was getting FreeBSD to support BATMAN mesh networks. BATMAN is a routing protocol developed by Freifunk to build city-scale open Wi-Fi networks based on the principles of net-neutrality.

Concretely, that consisted of porting the batman-adv kernel module from Linux to FreeBSD (as batman_adv). This makes use of the LinuxKPI, which is a kernel interface for translating Linux calls to FreeBSD code, and the new Netlink support in FreeBSD.

Q: What have you learned from this experience so far? 

A lot!

More specifically, I’ve learned loads about the internals of the Linux and FreeBSD network stacks, and I now feel much more comfortable navigating through their respective sources and tracking down network-related issues. I’ve also learned how to use the excellent kernel debugging tools FreeBSD provides (kgdb, dtrace, and, most importantly, printf ;)).

Overall I feel like I’ve progressed a lot as a developer in a very short time and gained a lot of transferable experience!

Q: How has working with the FreeBSD Project been? 

Wonderful! It’s always a pleasure to work on open-source projects. People in the FreeBSD community are very responsive and willing to give a hand, and I very much appreciated having a mentor (hi mmokhi@!) to guide me through the parts I got stuck on.

I look forward to continuing to work on FreeBSD in the future!

The Foundation has continued our successful partnership with the University of Waterloo Co-Op Program. Since 2017 we’ve had 15 interns, some having returned for more than one internship. We’ve also had two interns become full-fledged committers, and many continue to contribute. We sat down with this year’s Summer Co-Op Student to learn more about them and why they chose to work with FreeBSD.

Name: Naman Sood

Q: Tell us a little bit about yourself and where you are in your education journey.

I’m from India, and I came to Canada in 2019 to attend the University of Waterloo and study computer science. I’m currently halfway through my fourth year, and intend to graduate in Spring 2024.

Q: How many co-ops have you held?

FreeBSD was my fifth co-op term.

Q: Why did you want to work for the FreeBSD Foundation?

I’ve always enjoyed writing low-level code that deals with the nitty-gritty of computer hardware and provides a neat interface to other programs. The FreeBSD Foundation provided a unique opportunity to actually work on a real-world system used by people worldwide that involved exactly this kind of work. In addition to that, the experience of working in an open source ecosystem was an incredible learning experience, in terms of making me feel more comfortable contributing to the software I use every day.

Q: What are you hoping to learn from this internship?

The biggest thing I wanted to take away from this internship was having some experience with hacking on a real, production-ready operating system kernel. The operating systems course at my university was fantastic, but it was more of a guided tour of overall concepts. It skated over a lot of the intricate details that I think make working at a low level fun, and FreeBSD gave me practice and experience working exactly in this sort of an environment.

Q: What are you currently working on?

I’m currently trying to port parts of the VPS subsystem for FreeBSD (http://www.7he.at/freebsd/vps/) from FreeBSD 10 to 14 – specifically, I’m looking to port TCP checkpointing and failover across processes. This would be useful in case, for example, if you had a multi-process web server and one process died, it could hand off its TCP connection to another process. From the client’s perspective, things could continue to work unimpeded even in the face of this failure.

Q: How has the FreeBSD experience been so far?

It’s been great! There have been challenges, both technical and social, that arise naturally as a consequence of being a large, volunteer-driven open source software project. But those challenges are what I came here to face, and I’ve had an extremely informative and enjoyable time with the work that I was able to do.

Introducing students to FreeBSD continues to be a high priority for the Foundation. This year, in addition to our participation in Google Summer of Code and the University of Waterloo Co-Op program, the Foundation hired Jake Freeland, a previous GSoC student, to intern with us for the summer. We sat down with Jake to learn more about him and the work he has been doing to support FreeBSD.

Name: Jake Freeland

Q: Tell us a little bit about yourself and where you are in your education journey.

I have been interested in computer hardware for as long as I can remember. This characteristic naturally led me into operating systems, the software that gets closest to the hardware. I am currently a student at the University of Minnesota – Twin Cities that is graduating with a B.S. in Computer Science in December 2023.

Q: How many internships have you held?

I have worked with the FreeBSD Foundation once before, in 2022, on behalf of the Google Summer of Code initiative.

Q: Why did you want to work for the FreeBSD Foundation?

FreeBSD immediately came to mind when I started seeking internships. I had prior experience as a system administrator and FreeBSD was one of my favorite operating systems to work with. I knew their community was knowledgeable and I figured that contributing to the project would be an excellent way to transition into kernel development.

Q: What are you hoping to learn from this internship? 

My experience with FreeBSD has taught me how to work with large codebases. I feel comfortable traversing their src tree and I have become accustomed to formatting my code changes into reviewable commits/patches. Working with the Capsicum security sandbox has also taught me to think with security in mind. I feel I have gained enough intuition to detect and audit code for major security issues.

Q: What are you currently working on?

I started the internship by extending capability violation tracing in FreeBSD’s ktrace facility. With my changes, developers can trace and collect verbose capability violation diagnostics when a program is not in capability mode.

Next, I isolated FreeBSD’s system logging utility, syslogd, in a Capsicum security sandbox. The syslogd daemon runs with root privileges, so it is a high profile target for security attacks. Putting syslogd into a sandboxed environment should prevent detrimental effects in the case of a syslogd security vulnerability. With this experience, I created a how-to guide on sandboxing programs using Capsicum: https://cdaemon.com/posts/capsicum.

Q: How has the FreeBSD experience been so far?

I enjoyed working with the FreeBSD Foundation and plan to continue contributing to the project. I was particularly pleased to see that the Foundation is acknowledging the need for more young developers; I will be working with them to pilot a new program to introduce college students to FreeBSD.

Mark your calendars! The November 2023 FreeBSD Vendor Summit will take place November 2-3, 2023 at the NetApp Campus in San Jose, CA. The Vendor Summit will feature a single track of talks on both days. 

More details on the schedule and travel information will be available soon. In the meantime we are asking for your talk proposals now.  Talks should be technical in nature and aim for 30-35 minutes in length with an additional 10-15 minutes available for Q&A and will be given in person.  Proposals for talks should include a brief abstract of the topic as well as a brief bio of the speaker(s).  If you need more or less time, please include that detail in your proposal.  Please submit talk proposals to devsummit@FreeBSD.org by September 26, 2023.

If you have any questions, please feel free to contact the organizers via the email above. Thank you to NetApp for hosting the summit.

There are different ways to measure how work on FreeBSD is progressing such as the rate of commits, the number of developers, the number of FreeBSD ports, and so on. By one measure, the number of Foundation-funded projects, we are in a boom cycle. As of the time of writing, the FreeBSD Foundation has contracts open for 12 different projects. Some projects we have written about in past newsletters, others have only begun recently. What follows is a summary of this contracted work as well as some noteworthy development by Foundation employees. 

Contracted Work 

Documentation and Testing Internship 

Starting in July, Yan-Hao Wang began a summer internship with the Foundation to work on a variety of tasks. To start, Yan-Hao will focus on improving our documentation tooling. One deliverable is to build an online editor designed solely to make creating and editing man pages as simple as possible. A second is to develop an “expert system” for FreeBSD man pages and other documentation. This best-effort and proof-of-concept deliverable will involve importing FreeBSD documents such as man pages and the Handbooks into a vector database so that large language models like ChatGPT can “read” them in order to offer better answers when queried with FreeBSD questions. Making improvements to our testing framework is a second general goal of the summer’s work. For example, Yan-Hao will add missing tests for many of the userland tools under /bin, /sbin, /usr/bin, and /usr/sbin as well as libxo. Finally, some miscellaneous deliverables include updating the FreeBSD Jenkins tinderbox and developing a support roadmap for RPI4 support. 

Addressing OpenSSL 3 / LLVM 16 Ports Fallout 

A major obstacle to releasing FreeBSD 14.0, one that delayed the original release schedule, was the version of OpenSSL in the base system. With the end-of-life for OpenSSL 1.1.1 planned for September 2023, it was imperative to move to OpenSSL 3 prior to the release. Foundation team member Pierre Pronchery along with other members of the FreeBSD development community have mostly completed the update, however lots of code in both the base system and the ports tree that depend on OpenSSL require fixes to work with this new major version. Around the same time OpenSSL was updated in the base system, LLVM was updated to version 16, which also introduced some breaking changes, especially in the ports tree. Most of the critical issues with OpenSSL 3 and LLVM 15 have already been fixed, but with LLVM 16 there are approximately 800 additional ports that fail to build resulting in an additional 2800 dependent ports that are skipped in a full ports tree build. Muhammad Moinur (Moin) Rahman will complete the time-consuming and tedious work to fix all port issues related to the update to OpenSSL 3 and LLVM 16. 

SIMD-enhanced libc for amd64 

Modern computer architectures provide SIMD (single instruction multiple data) instruction set extensions to operate on multiple data at once. 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), to speed up most C programs. 

Commonly used for numerical applications such as video codecs, graphics rendering, and scientific computing, use of SIMD techniques also aids in basic data processing tasks such as those implemented by libc functions. While other libc implementations already provide SIMD enhanced variants of standard libc functions, the FreeBSD libc largely does not. The objective of this project by Robert Clausecker is to provide such SIMD-enhanced versions of relevant libc library functions and thus improve the performance of software linked against it. As these libc functions are used by most software available for FreeBSD, these enhancements are projected to give a broad benefit for a wide range of programs. The primary focus of the project is amd64 with the aim to produce SIMD optimised implementations based on the architecture levels defined by the x86_64 psABI. 

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

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. 

Networking Summer Internship 

Naman Sood is a FreeBSD Foundation summer intern who has been working on networking related tasks such as (1) completing work started by Luiz Amaral to allow pfsync traffic to be carried over IPv6 and (2) updating work to implement RFC 4787 REQs 1 and 3 for pf full cone NAT. Naman has also fixed bugs in pw(8) and du(1) and has begun to explore completing tcp checkpoint and failover work started by Klaus P. Ohrhallinger. 

Security Sandboxing Using ktrace(1) 

Starting in June, Jake Freeland began an internship with the Foundation to work on Capsicum-related projects. Capsicum was built to limit the capabilities given to applications and libraries. The core idea is intuitive; once capability mode is entered, resource acquisition and external communication is limited. It is fairly easy to design a program around this principle, but problems arise when applications that were not designed to be sandboxed need to work in this environment. It can be difficult to determine which actions cause Capsicum violations and it is impossible to pre-open resources that have not been requested or named yet. Furthermore, the developer needs to be fully acquainted with the program before they can begin to implement Capsicum functionality. Due to these challenges, progress and development surrounding the framework has waned in recent years. 

The internship will involve working on a number of projects that, as a whole, aim to revitalize Capsicum. The primary goal is to enhance and ease the experience for developers who wish to Capsicumize their existing programs. The biggest enemy of Capsicum is its large learning curve. Refactoring a program to support capability mode often requires the developer to know what causes Capsicum violations and know how to restructure the given program to avoid violations. Sometimes this process is trivial, but larger programs often need resources on-demand and figuring out how to serve these needs can be difficult. Extending the number of tools available to the developer for convenient program Capsicumization will decrease the learning curve. If Capsicumization is easy, then more developers will adopt it. 

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), which logs kernel activity for a specified process. While ktrace can record and return extra information about your program’s violations, this can be inconvenient because ktrace only reports the first capability violation before the program terminates. 

A new ktrace extension written by Jake can record violations when a program is not in capability mode. This means capability violation tracing can be run on an unmodified program and since the program is not required to be run in capability mode, it will still acquire resources and execute normally even when capability violations occur. 

Upon completion of the ktrace extension Jake will begin to capsicumize various utilities, including syslogd(8), NFS daemons, ggatec(8)/ggated(8), tftpd(8), ntpd(8), and libarchive(8). 

Wireless Internship 

En-Wei Wu, a 2022 Google Summer of Code Contributor, began an internship with the FreeBSD Foundation in early 2023 to work on FreeBSD wireless drivers and tools. The work is divided into three components. 

Continuous Integration Enhancements 

FreeBSD’s Jenkins-based CI infrastructure currently initiates a job every time a developer pushes a commit to the FreeBSD src repository. While this is valuable for identifying newly introduced problems, it would be even better to easily identify these issues before they are pushed to the main branch. This goal can be achieved by making CI tests more accessible to developers in a pre-commit environment and also by having private FreeBSD runners that the popular git hosting services could leverage to create CI infrastructure for people pushing to private branches. To that end, Muhammad Moinur Rahman aims to take CI scripts written by Li-Wen Hsu and make them available to developers as part of the build system. Similar to how make universe or make tinderbox builds all supported architectures, make ci would achieve something similar for all the supported builds. A parallel goal is to make it possible for developers to run individual CI jobs when debugging problems. The hope is that this flexibility will also allow for others to integrate these builds / scripts into other CI tools like Cirrus CI that are run from Github. 

Improving the kinst DTrace provider 

DTrace is a framework that gives administrators and kernel developers the ability to observe kernel behavior in real time. DTrace has kernel modules called “providers”, which perform a particular instrumentation in the kernel using “probes”. kinst is a new DTrace provider created by Christos Margiolis and Mark Johnston as part of GSOC 2022 that allows for instruction-level tracing, that is, for a given kernel function, a user can trace each instruction in it. The provider is available in FreeBSD 14.0. 

kinst probes take the form of kinst::<function>:<offset>, where <function> is the kernel function to be traced, and <offset> is the specific instruction. The offsets can be obtained from the function’s disassembly using kgdb(1). For example, the following command will trace vm_fault()’s first instruction each time it executes: 

This project, which was completed in late July, implemented inline function tracing. In order to achieve this functionality, the DWARF debugging standard was used to be able to detect inline calls and handle them accordingly. DWARF’s and kinst’s functionality were leveraged to address some of the shortcomings of FBT, such as the tail-call optimization problem (chapter 20.4 of the DTrace manual) and the absence of inline tracing capabilities. 

Project deliverables included: 

FreeBSD as a Tier I cloud-init Platform 

cloud-init is the standard way of provisioning servers in the cloud. Unfortunately, cloud-init’s support for operating systems other than Linux is 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 I platform. To remedy this, the FreeBSD Foundation has contracted Mina Galić to bring FreeBSD cloud-init support on par with Linux support. The project deliverables include completing an extraction of certain networking classes, implementing ifconfig(8) and login.conf(5) parsers, implementing IPv6 configuration, creating devd rules for Azure, and writing Handbook documentation about productionizing FreeBSD. 

A number of project milestones were completed in the last quarter: 

These are used by several cloud providers to initialize a temporary network before retrieving the actual configuration. 

The hope is that with the next cloud-init release, Vultr can be convinced to switch their FreeBSD images to cloud-init. 

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, shaving off a few more milliseconds from the boot time. 

The next steps will be to continue work on 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. 

OpenStack on FreeBSD 

OpenStack is an open-source cloud operating system for many kinds of resources, from virtual machines, containers, to bare-metal servers. OpenStack’s control plane mainly targets Linux and FreeBSD is only unofficially supported as a guest operating system. Users can spawn FreeBSD instances on the open cloud platform, but it is not currently possible for administrators or operators to set up OpenStack deployments running on FreeBSD hosts. Given the increasingly important role of cloud-based deployments, and the popularity of OpenStack with various cloud providers, the FreeBSD Foundation has contracted Chin-Hsin Chang to port OpenStack components, so the system as a whole can be run on FreeBSD hosts. 

The Linux-based OpenStack components to be ported to FreeBSD/amd64 include, but are not limited to: 

As of the second quarter of 2023, some key achievements include: 

Work has begun to port nova-novncproxy and nova-serialproxy, which will increase the ways the instance console can be accessed. To lower the threshold for those who want to test the work, the development environment has also been migrated from a physical to a virtual instance. Anyone interested in testing should be aware that there is still a problem running bhyve VMs on top of Linux KVM. A detailed write-up of the issue can be found at https://hackmd.io/@starbops/SkdJON2un. Other work planned for the near future includes improving the console proxy services to make the overall workflow more fluent. Step-by-step documents for constructing a proof-of-concept site can be found at https://github.com/openstack-on-freebsd/docs. The patched version of each OpenStack component is under the same GitHub organization. 

Snapshots on Filesystems Using Journaled Soft Updates 

The UFS/FFS filesystem has the ability to take snapshots. Because the ability to take snapshots was added after soft updates were written, they were fully integrated with soft updates. However, when journaled soft updates were added in 2010, they were never integrated with snapshots. So, snapshots cannot be used on filesystems running with journaled soft updates. There are two instances where UFS snapshots are still important. First, they allow reliable dumps of live filesystems, which avoids possibly hours of down time. Second, they allow running background fsck. Similar to the need for scrub in ZFS, fsck needs to be run periodically to find undetected disk failures. Snapshots allow fsck to be run on live filesystems rather than needing to schedule down time. This work requires extensive changes in the UFS/FFS soft updates and snapshot kernel code and also in the fsck_ffs utility. 

The work is divided between two milestones. Milestone 1, which was completed in late 2022 enables snapshots when running with journaled soft updates. These snapshots are usable for doing background dumps on a live filesystem. Milestone 2 involves extending fsck_ffs to be able to do a background check using a snapshot on a filesystem running with journaled soft updates. As of mid-August, the changes that are needed in the kernel and fsck_ffs are complete and testing has gone smoothly. 

Related to this project, Kirk has been working on a number of filesystem panics that were recently reported as well as a few older UFS bugs. These included bugs that could trigger false corruption warnings in the UFS superblock integrity checks. All the fixes were tested in time for inclusion in FreeBSD 14 and those relevant to FreeBSD 13 were MFCed. 

WiFi 

The FreeBSD WiFi stack needs ongoing maintenance and development to keep up with new standards and devices. The Foundation is funding Bjoern Zeeb to integrate support for current-generation Intel WiFi devices by migrating to the dual-licensed upstream driver from the Linux kernel.  Under the contract, Bjoern also takes on related wireless work such as development of the 802.11 LinuxKPI and integration of other wireless drivers, such as those from Realtek.

In the latest quarter nearly all of Bjoern’s time was dedicated to LinuxKPI updates in preparation for an iwlwifi(4) update as well as updates to other drivers such as rtw88, rtw89, mt76, and ath10k, as well as preparations for ath11k and ath12k.  Most of this work is already in the tree and will soon be connected to the build for people to test.

Other Foundation Work 

As we reported in our 2023 Q2 status report entry, 339 src, 155 ports, and 20 doc tree commits identified the FreeBSD Foundation as a sponsor. A sample of this work includes: 

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. Foundation team member Pierre Pronchery spoke about driver harmony between the BSDs and En-Wei Wu discussed wtap work completed under contract with the Foundation. 

Base OpenSSL 3 Update 

As already mentioned, the pending removal of upstream support for the 1.1 branch of OpenSSL was a major obstacle to releasing FreeBSD 14.0. New Foundation team member, Pierre Pronchery, along with Ed Maste and other members of the FreeBSD developer community got to work updating our base OpenSSL to version 3. 

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 Internet’s infrastructure. 

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 a 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 Long Term Support, 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 2.000 files. Perhaps as a consequence, its build system is relatively complex and normally requires Perl, which has been removed from FreeBSD’s base system since 5.0-RELEASE. Thankfully however, it was possible to import and set up OpenSSL’s 3.0.9 release the FreeBSD way, and it is now part of the base system as planned for FreeBSD’s 14.0 release. 

It is an understatement to mention that OpenSSL 3 is a new major release. 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 away into a “legacy” module, it is also possible to restrict the implementation to 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 when writing these lines). 

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. 

Bump amd64 MAXCPU from 256 to 1024 

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. Foundation team member Ed Maste and other developers have made a number of changes 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.

FreeBSD on Microsoft HyperV and Azure 

Li-Wen Hsu, Wei Hu, and other member of the FreeBSD Azure Release Engineering Team, along with Souradeep Chakrabarti <schakrabarti@microsoft.com>, and other members of the Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com> have been working to add FreeBSD ARM64 architecture support to Azure. Part of that work has involved publishing images to the Azure community gallery. There are some testing images available in the project’s testing public gallery, named `FreeBSDCGTest-d8a43fa5-745a-4910-9f71-0c9da2ac22bf`: 

To use them, when creating a virtual machine: 

Work in progress includes: 

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

Wei Hu and Souradeep Chakrabarti from are working on several Microsoft-sponsored tasks, including: 

Open tasks: 

Google Summer of Code 

Coding for the 2023 edition of GSoC has just passed the midway point and the progress of the seven FreeBSD projects are documented on the wiki. Foundation team members are serving as our organization administrators and three projects are being mentored by people connected to the Foundation. 

CI Test Harness For Bootloader 

FreeBSD supports multiple architectures, file systems, and disk-partitioning schemes. For this project, Sudhanshu Mohan Kashyap <smk@FreeBSD.org>, is writing a Lua script to permit testing the boot loader for all these combinations for tier 1 and tier 2 architectures. If time permits, further exploration may be done to integrate the scripts into the existing build infrastructure (either Jenkins or Github Actions) to generate a comprehensive summary of the test results. 

Currently any developer changes may 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 the full make universe required today. These attributes allow developers to routinely use the script, and allow integration into the CI pipelines without undue cost. 

Physical memory compaction for the FreeBSD kernel 

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. The goal of this GSoC work 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. 

Integrate mfsBSD into the release building tools 

mfsBSD is a toolset created by Martin Matuška to create small-sized but full-featured mfsroot based distributions of FreeBSD. That is, it loads files from a storage device and stores them in memory via a memory file system (MFS). As part of this project, Soobin Rho <soobinrho@FreeBSD.org> will create 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.