FreeBSD Mail Archives

Date:      Thu, 27 Jul 2023 15:37:48 +0000
From:      Lorenzo Salvadore <salvadore@freebsd.org>
To:        freebsd-hackers@freebsd.org
Cc:        freebsd-current@freebsd.org, freebsd-stable@freebsd.org
Subject:   FreeBSD Status Report - Second Quarter 2023
Message-ID:  <ZMKPTAwBF34-FYVb@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

FreeBSD Status Report Second Quarter 2023

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

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

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

Have a nice read.

Lorenzo Salvadore, on behalf of the Status Team.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A rendered version of this report is available here:
https://www.freebsd.org/status/report-2023-04-2023-06/

Table of Contents

• FreeBSD Team Reports
□ FreeBSD Core Team
□ FreeBSD Foundation
□ FreeBSD Release Engineering Team
□ Cluster Administration Team
□ Continuous Integration
□ Ports Collection
• Projects
□ Cirrus-CI
□ BATMAN support in the FreeBSD kernel
□ FreeBSD support on LinuxBoot
• Userland
□ OpenSSL 3 in base
□ Linux compatibility layer update
□ Service Jails — automatic jailing of rc.d services
□ Security Sandboxing Using ktrace(1)
□ NVMe over Fabrics
• Kernel
□ Boot Performance Improvements
□ CI Test Harness For Bootloader
□ Physical memory compaction for the FreeBSD kernel
□ Increasing MAXCPU
□ SquashFS port for FreeBSD kernel
□ Pf Improvements
□ Network Interface API (IfAPI)
□ Making Netgraph Lock-Free
• Architectures
□ SIMD enhancements for amd64
□ Integrate mfsBSD into the release building tools
• Cloud
□ FreeBSD as a Tier 1 cloud-init Platform
□ OpenStack on FreeBSD
□ FreeBSD on Microsoft HyperV and Azure
□ FreeBSD on EC2
• Documentation
□ Documentation Engineering Team
• Ports
□ KDE on FreeBSD
□ GCC on FreeBSD
□ Puppet
□ MITRE Caldera on FreeBSD
□ Wazuh on FreeBSD
• Third Party Projects
□ PkgBase.live
□ Containers and FreeBSD: Pot, Potluck and Potman

FreeBSD Team Reports

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

FreeBSD Core Team

Contact: FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team is the governing body of FreeBSD.

DevSummit 202305

The Core Team has presented the status update at the FreeBSD Developer Summit,
17th–18th May. Slides are available at https://wiki.freebsd.org/DevSummit/
202305.

FreeBSD 14

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

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

Meetings with The FreeBSD Foundation

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

Matrix IM solution

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

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

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

Code of Conduct Committee

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

Commit bits

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

FreeBSD Foundation

Links:
FreeBSD Foundation URL: https://www.freebsdfoundation.org
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://www.freebsdfoundation.org/donate/
Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/
freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://www.freebsdfoundation.org/journal/
Foundation News and Events URL: https://www.freebsdfoundation.org/
news-and-events/

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

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

Happy 30th birthday, FreeBSD!

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

Fundraising

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

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

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

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

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

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

Partnership Program

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

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

Some other partnership-related activities this quarter:

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

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

• I am also pursuing grant opportunities with bodies including:

□ NSF Secure and Trustworthy Cyberspace (SaTC)

□ Sovereign Tech Fund

□ NGI.

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

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

• Open Forum Europe

• CHIPS Research and Development.

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

OS Improvements

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

• Continuous Integration

• FreeBSD as a Tier 1 cloud-init Platform

• OpenSSL 3 in base

• OpenStack on FreeBSD

• Security Sandboxing Using ktrace(1)

• SIMD enhancements for amd64

Here is a sampling of other Foundation-sponsored work:

• Bug fixes for fsck_ffs(8)

• Bug fixes for killpg(2)

• Improvements to hwpmc

• Improvements to vmm

• Port fixes and workarounds for LLVM 16 and OpenSSL 3.0

• Port kinst to RISC-V and related DTrace work

• Update of libfido2 to version 1.9.0

• Various LinuxKPI 802.11 improvements

• Various RISC-V improvements

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

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

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

Continuous Integration and Quality Assurance

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

Advocacy

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

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

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

• Helped to organize and attended the May 2023 Developer Summit which took
place May 17-18, 2023 in Ottawa, Ontario

• Hosted a table and was the Tote Bag Sponsor of BSDCan, May 17-20, 2023 in
Ottawa, Ontario

□ Trip reports can be found on the blog

• Celebrated the Project’s 30th Birthday at BSDCan with cake and printed
copies of the special 30th Anniversary Edition of the FreeBSD Journal

• Secured a FreeBSD Workshop and Talk at FOSSY, July 13-16, 2023, in
Portland, Oregon

• Secured our Silver Sponsorship for EuroBSDCon 2023 taking place September
14-17, 2023 in Coimbra, Portugal

• Secured our booth for All Things Open, October 15-17, 2023 in Raleigh,
North Carolina

• Began planning the FreeBSD Fall Vendor Summit

• Welcomed two New Team Members: Greg Wallace and Pierre Pronchery

• Published April and June Newsletters

• Celebrated the FreeBSD Day and the Project’s 30th Anniversary on June 19
and through the week with special videos and blog posts

• Additional Blog Posts:

□ EuroBSDcon 2023 Travel Grant Application Now Open - Note: Applications
close August 2, 2023

□ AsiaBSDcon Trip Report

• FreeBSD in the News:

□ InfoWorld: Happy 30th FreeBSD!.

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

You can find out more about events we attended and upcoming events at https://
www.FreeBSDfoundation.org/news-and-events/.

Legal/FreeBSD IP

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

Go to https://www.freebsdfoundation.org to find more about how we support
FreeBSD and how we can help you!

FreeBSD Release Engineering Team

Links:
FreeBSD 13.2-RELEASE schedule URL: https://www.freebsd.org/releases/13.2R/
schedule/
FreeBSD 14.0-RELEASE schedule URL: https://www.freebsd.org/releases/14.0R/
schedule/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/
ISO-IMAGES/

Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>

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

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

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

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

Sponsor: Tarsnap Sponsor: The FreeBSD Foundation

Cluster Administration Team

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration
/#t-clusteradm

Contact: Cluster Administration Team <clusteradm@FreeBSD.org>

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

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

• Regular support for FreeBSD.org user accounts.

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

• Enable mirroring of https://www.FreeBSD.org and https://docs.FreeBSD.org in
the FreeBSD project-managed mirrors.

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

Work in progress

• Large-scale network upgrade at our primary site.

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

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

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

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

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

FreeBSD Official Mirrors Overview

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

The hardware and network connection have been generously provided by:

• Bytemark Hosting

• Cloud and SDN Laboratory at BroadBand Tower, Inc

• Department of Computer Science, National Yang Ming Chiao Tung University

• Equinix

• Internet Association of Australia

• Internet Systems Consortium

• INX-ZA

• KDDI Web Communications Inc

• Malaysian Research & Education Network

• Metapeer

• NIC.br

• Your.Org

• 365 Data Centers

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

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

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

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

Continuous Integration

Links:
FreeBSD Jenkins Instance URL: https://ci.FreeBSD.org
FreeBSD CI artifact archive URL: https://artifact.ci.FreeBSD.org
FreeBSD Jenkins wiki URL: https://wiki.FreeBSD.org/Jenkins
Hosted CI wiki URL: https://wiki.FreeBSD.org/HostedCI
3rd Party Software CI URL: https://wiki.FreeBSD.org/3rdPartySoftwareCI
Tickets related to freebsd-testing@ URL: https://bugs.freebsd.org/bugzilla/
buglist.cgi?bug_status=open&email1=testing%40FreeBSD.org&emailassigned_to1=1&
emailcc1=1&emailtype1=equals
FreeBSD CI Repository URL: https://github.com/freebsd/freebsd-ci
dev-ci Mailing List URL: https://lists.FreeBSD.org/subscription/dev-ci

Contact: Jenkins Admin <jenkins-admin@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

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

Important completed tasks:

• FreeBSD-stable-13-amd64-gcc12_build job has been added.

• Build environment of main and stable/13 branches has been changed to
13.2-RELEASE, and stable/12 has been changed to 12.4-RELEASE.

• *-build jobs using gcc12 are sending failure reports to dev-ci Mailing List
.

• Present Testing/CI Status Update in BSDCan 2023 Developer Summit

Work in progress tasks:

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

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

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

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

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

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

• Merge https://reviews.freebsd.org/D38815

• Merge https://reviews.freebsd.org/D36257

Open or queued tasks:

• Collecting and sorting CI tasks and ideas

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

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

• Adding drm ports building tests against -CURRENT

• Planning to run ztest tests

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

• Working with hosted CI providers to have better FreeBSD support

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

Sponsor: The FreeBSD Foundation

Ports Collection

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#
ports-contributing
FreeBSD Ports Monitoring URL: http://portsmon.freebsd.org/
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: René Ladan <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>

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

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

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

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

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

Projects

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

Cirrus-CI

Links:
FreeBSD Cirrus-CI Repositories URL: https://cirrus-ci.com/github/freebsd/
FreeBSD src CI URL: https://cirrus-ci.com/github/freebsd/freebsd-src FreeBSD
doc CI URL: https://cirrus-ci.com/github/freebsd/freebsd-doc

Contact: Brooks Davis <brooks@FreeBSD.org> Contact: Ed Maste <
emaste@FreeBSD.org> Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

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

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

Sponsor: DARPA Sponsor: The FreeBSD Foundation

BATMAN support in the FreeBSD kernel

Links:
Wiki page URL: https://wiki.freebsd.org/SummerOfCode2023Projects/
CallingTheBatmanFreeNetworksOnFreeBSD
Source code (Pull Request) URL: https://github.com/obiwac/freebsd-gsoc/pull/1

Contact: Aymeric Wibo <obiwac@FreeBSD.org>

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

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

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

Mentor: Mahdi Mokhtari

Sponsor: The Google Summer of Code '23 program

FreeBSD support on LinuxBoot

Contact: Warner Losh <imp@bsdimp.com>

Links:
LinuxBoot Project URL: https://www.linuxboot.org/+ BSDCan 2023 kboot talk
slides URL: https://docs.google.com/presentation/d/
1N5Jp6XzYWv9Z9RhhETC-e6tFkqRHvp-ldRDW_9h2JCw/edit?usp=sharing

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

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

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

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

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

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

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

Help Needed

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

2. Finish amd64 support.

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

4. It would be nice to add riscv64 support.

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

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

7. Testing it from the coreboot LinuxBoot.

Sponsored by: Netflix, Inc

Userland

Changes affecting the base system and programs in it.

OpenSSL 3 in base

Links:
OpenSSL Downloads URL: https://www.openssl.org/source/
OpenSSL 3.0 Has Been Released! URL: https://www.openssl.org/blog/blog/2021/09/
07/OpenSSL3.Final/
openssl-fipsinstall URL: https://www.openssl.org/docs/man3.0/man1/
openssl-fipsinstall.html

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

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

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

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

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

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

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

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

Sponsor: The FreeBSD Foundation

Linux compatibility layer update

Links:
Linuxulator status Wiki page URL: https://wiki.freebsd.org/Linuxulator
Linux app status Wiki page URL: https://wiki.freebsd.org/LinuxApps

Contact: Dmitry Chagin <dchagin@FreeBSD.org>

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

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

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

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

Service Jails — automatic jailing of rc.d services

Links:
D40369: Extend /usr/bin/service with the possibility to set ENV vars URL:
https://reviews.freebsd.org/D40369
D40370: Infrastructure for automatic jailing of rc.d-services URL: https://
reviews.freebsd.org/D40370
D40371: automatic service jails: some setup for full functionality of the
services in automatic service jails URL: https://reviews.freebsd.org/D40371

Contact: Alexander Leidinger <netchild@FreeBSD.org>

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

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

local_unbound_svcj_options=net_basic
local_unbound_svcj=YES

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

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

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

Security Sandboxing Using ktrace(1)

Links:
ktrace branch URL: https://github.com/jakesfreeland/freebsd-src/tree/ff/ktrace

Contact: Jake Freeland <jfree@FreeBSD.org>

Capsicumization With ktrace(1)

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

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

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

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

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

Violation Tracing Examples

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

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

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

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

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

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

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

# ktrace -t np unzip foo.zip
Archive: foo.zip
creating: bar/
extracting: bar/bar.txt
creating: baz/
extracting: baz/baz.txt
# kdump
1926 ktrace CAP system call not allowed: execve
1926 ktrace NAMI "/usr/bin/unzip"
1926 ktrace NAMI "/libexec/ld-elf.so.1"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/etc/libmap.conf"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/usr/local/etc/libmap.d"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/var/run/ld-elf.so.hints"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libarchive.so.7"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/usr/lib/libarchive.so.7"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libc.so.7"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libz.so.6"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libbz2.so.4"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/usr/lib/libbz2.so.4"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/liblzma.so.5"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/usr/lib/liblzma.so.5"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libbsdxml.so.4"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libprivatezstd.so.5"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/usr/lib/libprivatezstd.so.5"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libcrypto.so.111"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libmd.so.6"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libthr.so.3"
1926 unzip CAP system call not allowed: readlink
1926 unzip NAMI "/etc/malloc.conf"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/dev/pvclock"
1926 unzip NAMI "foo.zip"
1926 unzip CAP openat: restricted VFS lookup: AT_FDCWD
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/etc/localtime"
1926 unzip NAMI "bar"
1926 unzip CAP fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip CAP system call not allowed: mkdir
1926 unzip NAMI "bar"
1926 unzip NAMI "bar"
1926 unzip CAP fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip NAMI "bar/bar.txt"
1926 unzip CAP fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip NAMI "bar/bar.txt"
1926 unzip CAP openat: restricted VFS lookup: AT_FDCWD
1926 unzip NAMI "baz"
1926 unzip CAP fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip CAP system call not allowed: mkdir
1926 unzip NAMI "baz"
1926 unzip NAMI "baz"
1926 unzip CAP fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip NAMI "baz/baz.txt"
1926 unzip CAP fstatat: restricted VFS lookup: AT_FDCWD
1926 unzip NAMI "baz/baz.txt"
1926 unzip CAP openat: restricted VFS lookup: AT_FDCWD

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

1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/lib/libarchive.so.7"
1926 unzip CAP system call not allowed: open
1926 unzip NAMI "/usr/lib/libarchive.so.7"

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

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

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

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

Sponsor: FreeBSD Foundation

NVMe over Fabrics

Links:
nvmf2 branch URL: https://github.com/bsdjhb/freebsd/tree/nvmf2

Contact: John Baldwin <jhb@FreeBSD.org>

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

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

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

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

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

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

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

Sponsored by: Chelsio Communications

Kernel

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

Boot Performance Improvements

Links:
Wiki page URL: https://wiki.freebsd.org/BootTime
BSDCan talk slides URL: https://www.bsdcan.org/events/bsdcan_2023/sessions/
session/116/slides/44/BSDCan23-Firecracker.pdf

Contact: Colin Percival <cperciva@FreeBSD.org>

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

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

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

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

This work is supported by his FreeBSD/EC2 Patreon.

Sponsor: https://www.patreon.com/cperciva

CI Test Harness For Bootloader

Links:
FreeBSD Wiki GSoC Page
Github Project Link

Contact: Sudhanshu Mohan Kashyap <smk@FreeBSD.org>

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

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

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

Sponsor: The Google Summer of Code '23 program

Physical memory compaction for the FreeBSD kernel

Links:
GSoC project wiki page URL: https://wiki.freebsd.org/SummerOfCode2023Projects/
PhysicalMemoryAntiFragmentationMechanisms
Differential revision 40575 URL: https://reviews.freebsd.org/D40575
Differential revision 40772 URL: https://reviews.freebsd.org/D40772

Contact: Bojan Novković <bnovkov@FreeBSD.org>

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

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

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

Sponsor: The Google Summer of Code '23 program

Increasing MAXCPU

Links:
Review D36838: amd64: Bump MAXCPU to 1024 (from 256) URL: https://
reviews.freebsd.org/D36838

Contact: Ed Maste <emaste@FreeBSD.org>

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

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

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

Sponsor: The FreeBSD Foundation

SquashFS port for FreeBSD kernel

Links:
Wiki page URL: https://wiki.freebsd.org/SummerOfCode2023Projects/
PortSquashFuseToTheFreeBSDKernel
Source code URL: https://github.com/Mashijams/freebsd-src/tree/gsoc/squashfs

Contact: Raghav Sharma <raghav@FreeBSD.org>

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

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

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

Sponsor: The Google Summer of Code 2023 program

Pf Improvements

Links:
D40911 URL: https://reviews.freebsd.org/D40911
D40861 URL: https://reviews.freebsd.org/D40861
D40862 URL: https://reviews.freebsd.org/D40862
D40863 URL: https://reviews.freebsd.org/D40863
D40864 URL: https://reviews.freebsd.org/D40864
D40865 URL: https://reviews.freebsd.org/D40865
D40866 URL: https://reviews.freebsd.org/D40866
D40867 URL: https://reviews.freebsd.org/D40867
D40868 URL: https://reviews.freebsd.org/D40868
D40869 URL: https://reviews.freebsd.org/D40869
D40870 URL: https://reviews.freebsd.org/D40870

Contact: Kajetan Staszkiewicz <vegeta@tuxpowered.net>
Contact: Naman Sood <naman@freebsdfoundation.org>
Contact: Kristof Provost <kp@FreeBSD.org>

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

Backport OpenBSD Syntax

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

pfsync Protocol Versioning

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

pfsync: Transport over IPv6

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

SCTP

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

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

Network Interface API (IfAPI)

Links:
Original project page URL: link:https://wiki.freebsd.org/projects/ifnet

Contact: Justin Hibbits <jhibbits@FreeBSD.org>

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

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

Sponsor: Juniper Networks, Inc.

Making Netgraph Lock-Free

Links:
Wiki Page URL: https://wiki.freebsd.org/SummerOfCode2023Projects/
LocklessSynchronizationBetweenNodesInNetgraph
Repo URL: https://github.com/zinh88/epoch-netgraph

Contact: Zain Khan <zain@FreeBSD.org>

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

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

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

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

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

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

Sponsor: The Google Summer of Code '23 program

Architectures

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

SIMD enhancements for amd64

Links:
SIMD dispatch framework draft URL: https://reviews.freebsd.org/D40693
Project proposal URL: link:http://fuz.su/~fuz/freebsd/
2023-04-05_libc-proposal.txt

Contact: Robert Clausecker <clausecker@FreeBSD.org>

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

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

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

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

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

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

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

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

Sponsor: The FreeBSD Foundation

Integrate mfsBSD into the release building tools

Links:
Wiki Article URL: https://wiki.freebsd.org/SummerOfCode2023Projects/
IntegrateMfsBSDIntoTheReleaseBuildingTools
Project repository (integrate-mfsBSD-building branch) URL: https://github.com/
soobinrho/freebsd-src/tree/integrate-mfsBSD-building

Contact: Soobin Rho <soobinrho@FreeBSD.org>

What is mfsBSD?

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

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

Purpose

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

Location

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

Mentors: Juraj Lutter and Joseph Mingone

Sponsor: The Google Summer of Code '23 program

Cloud

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

FreeBSD as a Tier 1 cloud-init Platform

Links:
cloud-init Website URL: https://cloud-init.io/
cloud-init Documentation URL: https://cloudinit.readthedocs.io/en/latest/
cloud-init ongoing refactorization URL: https://github.com/canonical/cloud-init
/blob/main/WIP-ONGOING-REFACTORIZATION.rst

Contact: Mina Galić <freebsd@igalic.co>

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

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

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

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

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

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

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

Sponsor: The FreeBSD Foundation

OpenStack on FreeBSD

Links:
OpenStack URL: https://www.openstack.org/
OpenStack on FreeBSD URL: https://github.com/openstack-on-freebsd

Contact: Chih-Hsin Chang <starbops@hey.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

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

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

• Sorting out network connectivity issues inside the instances

• Able to spawn multiple instances

• Porting from Python 3.8 to 3.9.

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

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

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

Sponsor: The FreeBSD Foundation

FreeBSD on Microsoft HyperV and Azure

Links:
Microsoft Azure article on FreeBSD wiki URL: https://wiki.freebsd.org/
MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV

Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>
Contact: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

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

To use them, when creating a virtual machine: . In Select an Image step, choose
Community Images (PREVIEW) in Other items . Search FreeBSD

Work in progress tasks:

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

• Building and publishing ZFS-based images to Azure Marketplace

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

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

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

• Building and publishing snapshot builds to Azure community gallery

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

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

• Porting Hyper-V guest support to aarch64

□ https://bugs.freebsd.org/267654

□ https://bugs.freebsd.org/272461

Open tasks:

• Update FreeBSD related doc at Microsoft Learn

• Support FreeBSD in Azure Pipelines

• Update Azure agent port to the latest version

• Upstream local modifications of Azure agent

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

FreeBSD on EC2

Links:
FreeBSD/EC2 Patreon URL: https://www.patreon.com/cperciva

Contact: Colin Percival <cperciva@FreeBSD.org>

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

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

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

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

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

Documentation

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

Documentation Engineering Team

Link: FreeBSD Documentation Project URL: https://www.freebsd.org/docproj
Link: FreeBSD Documentation Project Primer for New Contributors URL: https://
docs.freebsd.org/en/books/fdp-primer/
Link: Documentation Engineering Team URL: https://www.freebsd.org/
administration/#t-doceng

Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>

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

During this quarter:

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

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

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

Porter’s Handbook

USES=nextcloud has been documented.

FDP Primer

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

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/
Translation/Weblate
Link: FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/

Q2 2023 Status

• 15 languages

• 183 registered users

• New Weblate server

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

Languages

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

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

• Dutch (nl) (progress: 1%)

• French (fr) (progress: 1%)

• German (de) (progress: 1%)

• Indonesian (id) (progress: 1%)

• Italian (it) (progress: 5%)

• Korean (ko) (progress: 32%)

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

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

• Polish (progress: 1%)

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

• Sinhala (si) (progress: 1%)

• Spanish (es) (progress: 33%)

• Turkish (tr) (progress: 2%)

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

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

FreeBSD Handbook working group

Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>

The Network chapter is being reworked.

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>

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

1. Redesign of the Documentation Portal

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

2. Redesign of the Manual Pages on web

Scripts to generate the HTML pages using mandoc. (Complete) Public instance
on https://man-dev.FreeBSD.org

3. Redesign of the Ports page on web

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

4. Redesign of the FreeBSD main website

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

Ports

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

KDE on FreeBSD

Links:
KDE/FreeBSD initiative URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Contact: Adriaan de Groot <kde@FreeBSD.org>

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

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

Infrastructure

Qt5 ports had various updates:

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

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

Qt6 ports had various updates:

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

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

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

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

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

KDE Stack

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

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

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

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

Related Ports

Deprecations:

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

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

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

Updates:

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

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

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

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

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

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

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

New Software:

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

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

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

GCC on FreeBSD

Links:
GCC Project URL: https://gcc.gnu.org/
GCC 10 release series URL: https://gcc.gnu.org/gcc-10/
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/
GCC 12 release series URL: https://gcc.gnu.org/gcc-12/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

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

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

• lang/gcc13, tracking GCC 13 releases;

• lang/gcc14-devel, tracking snapshots from the new GCC 14 upstream branch.

The *-devel ports

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

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

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

• LTO_BOOTSTRAP remains available for users who want it.

Those changes will be forwarded to the production ports.

The production ports

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

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

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

• update of GCC_DEFAULT to 13;

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

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

This will provide the following advantages:

• more testing with less exp-runs;

• fewer builds for ports users.

Puppet

Links:
Puppet URL: https://puppet.com/docs/puppet/latest/puppet_index.html

Contact: Puppet Team <puppet@FreeBSD.org>

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

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

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

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

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

MITRE Caldera on FreeBSD

Links:
MITRE Caldera URL: https://caldera.mitre.org/
Red Canary URL: https://www.redcanary.com/

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

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

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

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

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

Additionally, you can test a MITRE Caldera infrastructure easily using https://
github.com/alonsobsd/caldera-makejail or https://github.com/AppJail-makejails/
caldera from AppJail. AppJail is a good tool for managing jail containers from
the command line.

People interested in helping with the project are welcome.

Current version: 4.2.0

To Do

• Add Caldera testing infrastructure makejail.

• Add FreeBSD to platforms officially supported by MITRE Caldera, see https:/
/github.com/mitre/caldera/pull/2752.

• Add FreeBSD to platforms officially supported by Red Canary, see https://
github.com/redcanaryco/atomic-red-team/pull/2450.

Wazuh on FreeBSD

Links:
Wazuh URL: https://www.wazuh.com/

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

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

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

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

Currently, all Wazuh components are ported or adapted: security/wazuh-manager,
security/wazuh-agent, security/wazuh-server, security/wazuh-indexer, and
security/wazuh-dashboard.

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

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

Additionally, you can easily test a Wazuh single-node infrastructure
(All-in-one) using https://github.com/alonsobsd/wazuh-makejail or https://
github.com/AppJail-makejails/wazuh from AppJail. AppJail is a good tool for
managing jail containers from the command line.

People interested in helping with the project are welcome.

Current version: 4.4.4

TODO

• Add Wazuh cluster-mode infrastructure makejail (Work in progress)

• Add FreeBSD to platforms officially supported by Wazuh Inc; see https://
github.com/wazuh/wazuh-kibana-app/pull/5413

• Add FreeBSD SCA Policy (Work in progress)

Third Party Projects

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

PkgBase.live

Links:
Website URL: https://alpha.pkgbase.live/
Source URL: https://codeberg.org/pkgbase

Contact: Mina Galić <freebsd@igalic.co>

PkgBase.live, an unofficial repository for the FreeBSD PkgBase project, is back
alive.

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

Right now, we provide builds for:

• FreeBSD 13.2-RELEASE

• FreeBSD 13-STABLE

• FreeBSD 14-CURRENT

each for the following platforms:

• amd64

• aarch64

• armv7

• i386

You may notice that RISCv64 is gone for now.

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

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

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

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

Containers and FreeBSD: Pot, Potluck and Potman

Links:
Pot organization on GitHub URL: https://github.com/bsdpot

Contact: Luca Pizzamiglio (Pot) <pizzamig@FreeBSD.org>
Contact: Bretton Vine (Potluck) <bv@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>

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

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

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

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

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

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

As always, feedback and patches are welcome.

Sponsor: Honeyguide Group

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZMKPTAwBF34-FYVb>

Header And Logo

Peripheral Links

Site Navigation