FreeBSD Quarterly Status Report - Fourth Quarter 2021

Go to: [ bottom of page ] [ top of archives ] [ this month ]

From: Joseph Mingrone <jrm_at_FreeBSD.org>
Date: Fri, 11 Mar 2022 02:21:18 UTC

FreeBSD Quarterly Status Report 4th Quarter 2021

This report covers FreeBSD related projects for the period between October and
December. It is the fourth of four planned reports for 2021, and contains 19
entries. Highlights include faster boot times, more LLDB work, a base OpenSSH
update, and more wireless development.

Yours,
Pau Amma, Daniel Ebdrup, John-Mark Gurney, and Joe Mingrone

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents

• FreeBSD Team Reports
□ FreeBSD Foundation
□ Ports Collection
□ Documentation Engineering Team
□ FreeBSD Website Revamp - WebApps working group
• Projects
□ Enable ASLR by default for 64-bit executables
□ Boot Performance Improvements
□ LLDB Debugger Improvements
□ NXP LS1028A/1027A SoC support
□ sched_getcpu(2), membarrier(2), and rseq(2) syscalls
□ Base System OpenSSH Update
□ VDSO on amd64
• Kernel
□ The AVX bug on amd64
□ ENA FreeBSD Driver Update
□ Intel Wireless driver support
□ Kernel Crypto changes to support WireGuard
• Ports
□ KDE on FreeBSD
□ FreeBSD Office Team
• Third-Party Projects
□ helloSystem
□ Containers & FreeBSD: Pot, Potluck & Potman

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

FreeBSD Team Reports

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

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://www.FreeBSDFoundation.org/
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.

Here are some highlights of what we did to help FreeBSD last quarter:

Fundraising Efforts

We did it! We met our 2021 fundraising goal by raising $1,281,437!! On behalf
of the Foundation, I want to thank you for your financial support last year,
that will help us continue and increase our support for FreeBSD in 2022. In
addition, folks are already sending us their 2022 contributions, which is
incredibly heartwarming! We’ll start updating the fundraising meter for 2022 by
the end of January.

In this Quarterly Status report you’ll read about many of the areas we funded
in Q4 to improve FreeBSD and advocate for the Project (the two main areas we
spend money on). Check out reports on the externally funded projects like LLDB
support, Raid-Z Expansion, WireGuard, and wifi, as well as, internally
supported work like improved security, tier-1 architecture support, and
providing online opportunities to connect and educate the community.

If you want to help us continue our efforts, please consider making a donation
towards our 2022 fundraising campaign! https://www.FreeBSDFoundation.org/donate/.

We also have a Partnership Program for larger commercial donors. You can read
about it at https://www.FreeBSDFoundation.org/
FreeBSD-foundation-partnership-program/.

OS Improvements

During the fourth quarter, Foundation staff and grant recipients committed 472
src tree changes, 98 ports tree changes, and 11 doc tree changes. This
represents 41%, 41%, and 13% of src, ports, and doc commits identifying a
sponsor.

You can read about Foundation-sponsored projects in individual quarterly report
entries:

• The AVX bug on amd64

• Crypto changes for WireGurard

• Intel Wireless driver support

• LLDB Debugger Improvements

• Base System OpenSSH Update

• sched_getcpu(2), membarrier(2), and rseq(2) syscalls

• VDSO on amd64

Here is a small sample of other base system improvements from Foundation
developers this quarter that do not have separate report entries.

kern.proc.pathname canonical hard link

Some programs adjust their behavior depending on which name was used for
execution. For these programs, it is often important to have a consistent name
in argv[0], sysctl kern.proc.pathname, auxv AT_EXECPATH, and any procfs file
symlink. Before this work, all listed kernel interfaces tried to calculate some
name for the text vnode and returned the result. If the executed binary has
more than one hardlink, the returned names were arbitrarily chosen from the
list of valid names for the file. After work completed this quarter by
Foundation developer Konstantin Belousov, the system now holds the parent
directory and the name of the text file for the running image. This is used to
reconstruct the correct name of the text file when requested.

swapon/swapoff, file swapping

After work to fix asserts for character device vnode locking, there was a
report that swap on file code broke the VFS locking protocol. Some other
regressions in the swap on file were also identified. For instance, on
shutdown, filesystems were unmounted before swapoff, which makes swapoff panic
on page-in. These bugs were fixed and a swapoff(2) feature was added to avoid
some very conservative estimations for protection against memory and swap space
shortages.

fcntl(F_KINFO)

Application developers often request an interface to return the file path for
an open file descriptor. Our only useful facility for this was
kern.proc.filedesc sysctl, which is somewhat usable, but incurs too high of an
overhead when a process has many open files. A fcntl(F_KINFO) interface was
added, which returns a struct kinfo_file just for the specified file
descriptor. Among other useful data, kinfo_file provides the calculated path,
when available.

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.

Supporting FreeBSD Infrastructure

The Foundation provides hardware and support for the Project. In the fourth
quarter of 2021, we began searching for a new Australian mirror server. At the
time of writing, the server is purchased, but with delays obtaining components
and shipping, it may not be active until the second or third quarter of 2022.
Better and faster access to our sites for the Australian FreeBSD community is
coming.

FreeBSD Advocacy and Education

Much of our effort is dedicated to Project advocacy. This may involve
highlighting interesting FreeBSD work, producing literature, 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
continuing to attend virtual events and held a virtual vendor summit this past
November.

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

• Promoted and participated as a media sponsor for ALL Things Open 2021

• Committed to being a Media Sponsor for SCALE 19x

• Committed to hosting a stand at FOSDEM 2022

• Sent out the Fall 2021 Newsletter

• Held a FreeBSD Friday talk: The Writing Scholar’s Guide to FreeBSD, (text
equivalent)

• Gave a Foundation talk at Semi-Bug, November 16, 2021

• Gave Foundation and FreeBSD talks at Seagate OSPO, December 9, 2021

• Helped organize the 2 day FreeBSD Virtual Vendor Summit, November 18-19,
2021. Videos can be found on the Project’s Youtube Channel

• New blog and video posts:

□ FreeBSD Foundation Fall 2021 Update

□ 2021 in Review: Advocacy

□ 2021 in Review: Infrastructure Support

□ 2021 in Review: Software Development

□ Open Source Summit 2021 Conference Recap

• New How-To Guide: Introduction to 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!

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.

We currently have 46,700 ports in the Ports Collection according to FreshPorts.
There are currently 2,666 open ports PRs of which 611 are unassigned. This
quarter saw 9,535 commits from 166 committers on the main branch and 644
commits from 62 committers on the quarterly branch. Compared to last quarter,
this means a slight drop in the number of commits although more committers were
active, and a slight increase in the number of open PRs.

During the last quarter, we welcomed Dries Michiels (driesm@) and said goodbye
to kuriyama@ and fjoe@. There was also a change in portmgr: adamw@ stepped down
after five years of service and tcberner@ is now a full member of portmgr@.

Three new USES were introduced:

• magick to handle dependencies on ImageMagick

• nodejs to provide support for NodeJS (with a new default version NODEJS=
lts)

• trigger to handle pkg triggers using the TRIGGERS variable

The default version of PGSQL switched to 13. Furthermore, INSTALLS_ICONS has
been replaced by a trigger on gtk-update-icon-cache and the macro is no longer
functional.

As always, there were some updates to "big" packages: pkg was updated to
1.17.5, Chromium to 94.0.4606.81_3, and Firefox to 95.0.2_1,2. Ruby 3.1.0 and
Python 3.11 are now available for use by users and other ports.

Documentation Engineering Team

Links:
FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/
FreeBSD Documentation Project Primer for New Contributors URL: https://
docs.freebsd.org/en/books/fdp-primer/
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 FreeBSD
Doceng Team Charter.

No new documentation commit bit was granted during the last quarter, and only
one commit bit was safe kept.

Several tasks were completed related to the doc tree during the last quarter:

• A COPYRIGHT file was added in the root directory of the doc repository. The
license was also updated to reflect the current toolchain the project is
using now.

• Cleanup of Mailman information in the doc tree. Following mailing lists
migration from Mailman to Mlmmj, very old mailing lists were removed; most
of the work was made on English documents.

• Tag FreeBSD docset for 12.3-RELEASE.

• Update all ports/packages misc/freebsd-doc-*.

• Move articles/contributors/contrib-* files to the doc shared directory.

• Add option in documentation Makefile to archive/compress Documentation/HTML
offline files, a necessary step before updating https://
download.freebsd.org/ftp/. This was after a discussion with clusteradm@ to
update the offline assets (HTML/PDF).

• Add experimental support for EPUB output (books/articles).

• Talking with clusteradm@ to improve the performance of https://
www.freebsd.org and https://docs.freebsd.org.

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 will be divided into four phases:

1. Redesign of the Documentation Portal

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

Activate an edit link in the Documentation (books/articles) pointing to
GitHub and encouraging GitHub pull requests. (Complete)

2. Redesign of the Manual Pages on web

Scripts to generate the HTML pages using mandoc. (Work in progress)

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. (Not started)

Projects

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

Enable ASLR by default for 64-bit executables

Contact: Dawid Gorecki <dgr@semihalf.com>
Contact: Marcin Wojtas <mw@semihalf.com>

Address Space Layout Randomization (ASLR) is an exploit mitigation technique
implemented in the majority of modern operating systems. It involves randomly
positioning the base address of an executable and the position of libraries,
heap, and stack, in a process’s address space. Although over the years ASLR
proved to not guarantee full OS security on its own, this mechanism can make
exploitation more difficult.

The Semihalf team made an effort to switch on the address map randomization for
PIE (Position Independent Executables) & non-PIE 64-bit binaries. Once the
patch was merged to HEAD, the ASLR feature became enabled for all 64-bit
architectures.

Additionally, the mentioned change disabled SBRK, in order to allow utilization
of the bss grow region for mappings. It has no effect without ASLR, so it was
applied to all architectures.

TODO:

• Improve stackgap feature implementation.

• MFC to stable/13 branch.

Sponsor: Stormshield

Boot Performance Improvements

Links:
Wiki page URL: https://wiki.freebsd.org/BootTime
OS boot time comparison URL: https://www.daemonology.net/blog/
2021-08-12-EC2-boot-time-benchmarking.html

Contact: Colin Percival <cperciva@FreeBSD.org>

Colin Percival is coordinating an effort to speed up the FreeBSD boot process.
For benchmarking purposes, he is primarily using an EC2 c5.xlarge instance as a
reference platform and is measuring the time between when the virtual machine
enters the EC2 "running" state and when it is possible to SSH into the
instance.

This work started in 2017, and as of the end of September 2021 the FreeBSD boot
time was reduced from approximately 30 seconds to approximately 15 seconds.

During 2021Q4, further improvements have shaved more time off the boot process,
taking it down to roughly 10 seconds. A further 4 seconds of improvements are
in process.

In addition, the userland boot process is now being profiled using TSLOG,
making it possible to see flamecharts of the entire boot process; and the
ec2-boot-bench tool is now able to generate MP4 videos of the boot process by
taking snapshots of the EC2 VGA console.

Issues are listed on the wiki page as they are identified; the wiki page also
has instructions for performing profiling. Users are encouraged to profile the
boot process on their own systems, in case they experience delays which don’t
show up on the system Colin is using for testing.

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

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

LLDB Debugger Improvements

Links:
Moritz Systems Project Description URL: https://www.moritz.systems/blog/
freebsd-kgdb-support-in-lldb/
Progress Report 3 URL: https://www.moritz.systems/blog/
lldb-serial-port-communication-support/
Progress Report 4 URL: https://www.moritz.systems/blog/
lldb-freebsd-kernel-core-dump-support/
LLVM Git Repository URL: https://github.com/moritz-systems/llvm-project
libfbsdvmcore Git Repository URL: https://github.com/moritz-systems/
libfbsdvmcore

Contact: Kamil Rytarowski <kamil@moritz.systems>
Contact: Michał Górny <mgorny@moritz.systems>

According to the upstream description, "LLDB is a next generation,
high-performance debugger. It is built as a set of reusable components which
highly leverage existing libraries in the larger LLVM Project, such as the
Clang expression parser and LLVM disassembler."

FreeBSD includes LLDB in the base system. At present, it has some limitations
compared to the GNU GDB debugger, and does not yet provide a complete
replacement. This project spans from July 2021 to January 2022 and aims to make
LLDB suitable for debugging FreeBSD kernels.

The earlier part of the project was focused on improving compatibility between
LLDB and other servers implementing the GDB Remote Protocol. This was followed
by implementing a fully-featured serial port support and then support for
FreeBSD kernel core dumps (vmcores).

The LLDB client gained much improved support for connecting to the remote
server over a serial port, and the LLDB server gained support for accepting
communication over a serial port. This opened the possibility of using LLDB to
debug embedded devices that use the RS232 interface. It can also aid debugging
kernels on regular PCs as it does not rely on the network stack.

Support for FreeBSD vmcores has also been added to LLDB. This makes it possible
to inspect the crashed kernel state without having to resort to KGDB or
manually convert the vmcore into the standard ELF format supported by LLDB.

The introduced changes are expected to be shipped with LLDB 14.0.

Sponsor: The FreeBSD Foundation

NXP LS1028A/1027A SoC support

Contact: Kornel Dulęba <mindal@semihalf.com>
Contact: Artur Rojek <ar@semihalf.com>
Contact: Hubert Mazur <hum@semihalf.com>
Contact: Wojciech Macek <wma@semihalf.com>

The Semihalf team has been working on adding the FreeBSD support for the NXP
LS1028A SoC, as well as its GPU-less variant (NXP LS1027A).

NXP LS1028A/LS1027A SoC is a dual-core 64-bit ARMv8 Cortex-A72 application
processor with high-speed peripherals such as 2 Time-Sensitive
Networking-capable (TSN) Ethernet controllers, quad-port TSN-enabled switch,
PCIE, SD/MMC, USB3.0 and others.

The original support was extended in the following way:

• ENETC Ethernet driver

□ Add support for PHY interrupts

□ Fix VID/mcast address hash calculation

□ Serialize MDIO transactions

□ Allow loading driver as a module

• Improvements in the FSL SDHCI driver

□ Add support for HS200/HS400 modes

□ Add full support for software reset

□ Provide more accurate clk calculation

□ Implement pulse width detection errata

□ Fix vccq reconfiguration

• FLEX SPI NOR controller driver

• Additional features:

□ TMP461 thermal sensor driver

□ PCF85063 RTC driver driver

□ TCA6408 I2C GPIO expander driver

TODO:

• Improve MMC HS200/HS400 support for other SoCs using the FSL SDHCI
controller.

Sponsor: Alstom Group

sched_getcpu(2), membarrier(2), and rseq(2) syscalls

Contact: Konstantin Belousov <kib@FreeBSD.org>

Links:
Linux manpage for membarrier(2) URL: https://kib.kiev.ua/kib/membarrier.pdf
membarrier(2) implementation URL: https://reviews.freebsd.org/D32360
Linux manpage for rseq(2) URL: https://kib.kiev.ua/kib/rseq.pdf
rseq(2) and userspace bindings implementation URL: https://reviews.freebsd.org/
D32505

Linux provides a set of syscalls that allow to develop mostly syscall-less
scalable algorithms in userspace. The mechanisms are based on optimistic
execution using CPU-local data with the assumption that rare events like
context switches or signal delivery do not occur for the given calculation, and
if they do occur, rollback and restart is performed. This very high-level
approach is used, as I understand, for implementation of tools like URCU, fast
malloc allocators (tcmalloc) and other userspace infrastructure projects aimed
at large partitioned machines.

For instance, sched_getcpu(2) syscall returns the CPU id of the CPU where the
current thread is currently executing. On amd64, if available, we use a RDTSCP
or RDPID instruction to query the CPU id without changing CPU mode, otherwise
this is a light-weight syscall. Of course, the answer provided is obsolete the
moment it is created, even before it is returned to userspace. But it allows
seeding values in some structures that are valid for a long time (at the CPU
speed scale) and are automatically corrected on exceptional control flow events
like context switches, and userspace can either detect and rollback or sync and
rollback with the exceptions.

There are two cornerstone syscalls that allow userspace to implement these
efficient algorithms: membarrier(2) and rseq(2).

Membarrier is a facility that helps implementing fast CPU ordering barriers,
typically used for asymmetric/biased locking. In these lock implementation
schemes, the owner of the object often assumes that there are contenders/
parallel threads that need coordinating with. If some thread starts accessing
the same resource, then it is its duty to ensure correctness. Examples of
'traps' that fast code path utilize are reads from a dedicated page that is
unmapped by contenders, to switch the fast path to the slow one. Or we could
send a signal to all threads that potentially have access to that object, to
insert a barrier. Or we can use the membarrier(2) facility, which incurs
significantly less overhead than signalling all threads.

Membarrier(2) inserts a barrier, which is the typical underlying hardware
operation to ensure ordering, into the specified set of CPUs, if these CPUs are
executing the specified thread. If these CPUs are not executing the targeted
threads, it is assumed that sequential consistency guarantees from the context
switch are enough to fulfill the requirement of membarrier(2). Overall, the
fast path can be implemented without slow instructions, and the slow path
injects required fences into the fast path at the cost of IPI.

The facility to detect exceptional conditions in the userspace thread execution
was developed in Linux and called rseq(2). It is a feature often called
Restartable Atomic Sequences, which explains the acronym. The ability to
cheaply do that allows code longer than a single instruction to execute
atomically, without the need to propose and implement unsafe operations like
disabling preemption, which is not feasible for userspace. For instance, code
might use CPU-local resources, which otherwise does not cope well with context
switches. There cannot be an analog of critical_enter(9) in userspace. (A
facility to cheaply block signal delivery exists in FreeBSD, see sigfastblock
(2), but correctly using it is provably too hard to implement in
general-purpose code, esp. because it requires version-dependent coordination
with rtdl and libthr.)

rseq(2) takes per-thread block of memory, where the thread writes the current
CPU id (see sched_getcpu(2)) and specifies the block of critical code that must
be unwound if an exceptional situation like a context switch occurred while the
block was executing. The fast code path uses per-cpu data and typically does
not need any corrections, but would a context switch occur, transfer of control
to the abort handler informs userspace about the event. So instead of disabling
context switches, code can cheaply check for one after the calculation and
retry if needed.

An interesting rseq(2) implementation detail is that it is impossible (and not
needed) to access/update rseq structures from kernel during the actual context
switch, because we cannot access userspace from under a spinlock. In other
words, threads using rseq do not incur any performance cost from system-global
context switches. Instead, if the process registered for rseq(2), on any return
to user mode we check if any exceptional events happened while the thread was
in the kernel (context switches may happen only while the thread is in kernel
mode), and if a context switch indeed occured, we fire an ast to check whether
the program counter is inside the critical section and jump to the abort
handler if it is.

The implementations of membarrier(2) and rseq(2) are clean-room: I used Linux
manual pages as the reference and public discussions of the features for
clarifying corner cases. On Linux/glibc, there was no stable glibc interface to
the rseq facility. One proposed integration was committed then reverted from
glibc. It might be prudent to wait some more for the rseq(2) interface to
stabilize in glibc before providing it in our libc or to rely on tight
integration between kernel and userspace in our base system, and use ABI tricks
like symbol versioning to evolve the interface. There is no goal to be 100%
compatible with Linux anyway.

Sponsor: The FreeBSD Foundation

Base System OpenSSH Update

Links:
OpenSSH URL: https://www.openssh.com/
Announcement to freebsd-security@ URL: https://lists.freebsd.org/pipermail/
freebsd-security/2021-September/010473.html

Contact: Ed Maste <emaste@freebsd.org>

OpenSSH, a suite of remote login and file transfer tools, was updated from
version 8.7p1 to 8.8p1 in the FreeBSD base system.

NOTE: OpenSSH 8.8p1 disables the ssh-rsa signature scheme by default. For more
information please see the Important note for future FreeBSD base system
OpenSSH update mailing list post.

OpenSSH supports FIDO/U2F devices, and support is now enabled in the base
system.

Next steps include integrating U2F key devd rules into the base system, and
merging the updated OpenSSH and FIDO/U2F support to stable branches.

Sponsor: The FreeBSD Foundation

VDSO on amd64

Contact: Konstantin Belousov <kib@FreeBSD.org>

A VDSO, or Virtual Dynamic Shared Object, is a shared object (more commonly
called dynamic library) that is inserted into the executed image by a joint
effort of the kernel and the dynamic linker. It does not exists on disk as a
standalone .so, and there are no instructions in the ELF format that cause the
insertion. It is done by the system to implement some functionality for the C
runtime implementation components.

FreeBSD already has a lot of features typically done using VDSO (in Linux), but
really not requiring that complication. The main reason why it is possible is
the often mentioned co-evolution of the kernel and C runtime. We can naturally
introduce features that require implementation both in kernel, and support in
the userspace parts, since FreeBSD is developed as a whole. Surprisingly, it
also allows the kernel and dynamic linker to know much less (and not enforce
anything) about userspace consumers of interfaces.

For instance, a syscall-less wall clock was implemented long ago, by the kernel
providing a time hands blob in the shared page, and the C library knowing about
its location and the supported algorithms. There is no need for a VDSO that
interposes some libc symbols or provides services that are named by known
symbols to userland.

From all the years of experience with this pseudo-VDSO approach, the only
feature that was impossible to implement without providing real VDSO support
was the signal trampoline DWARF annotations, for the benefit of stack
unwinders.

When the kernel delivers signal to userland, it changes some key registers
(like the instruction pointer, the stack pointer, and whatever else is needed
by the architecture) and pushes the saved image of the whole usermode CPU state
(context) onto the user stack. Then, control is passed to a small piece of code
located in the shared page (signal trampoline), which calls the user handler
function and on return from the handler issues a sigreturn(2) syscall to reload
the old context.

From this description, it is clear that the state of the machine during
trampoline execution is quite different from the normal C calling frames.
Unwinders that handle things like C++ exceptions, Rust panics, or other similar
mechanisms in specific language runtimes, need to understand the specialness of
the trampoline frame. The current approach is to hardcode the detection of the
trampoline, e.g. by matching the instruction pointer against sysctl
kern.proc.sigtramp.

DWARF annotations are enough to provide the required information to unwinders
to make the trampoline frame not special anymore, but the problem is that there
is no way for unwinders to find the annotation without introducing even more
specialness. Instead, we can insert a VDSO that only serves to appear in the
enumeration of DSOs loaded into the process, with either dl_iterate_phdr(3)
(in-process) or r_debug (remote), with PT_GNU_EH_FRAME header pointing to the
root of DWARF info.

This is exactly what the VDSO on FreeBSD does: it wraps signal trampoline bits
and their DWARF annotation (.cfi) into a shared object, which is put into the
shared page and linked by rtld(1) into the set of preloaded objects upon image
activation.

Efforts were made to strip as many unneeded structures and as much padding as
possible from the VDSO image, because it consumes space in the shared page. It
was pushed as far as the common denominator of lld and ld.bfd allowed, with
several tricks done by linker scripts and some use of seemingly undocumented
linker options.

We need at least two VDSOs for amd64: a 64-bit one for native binaries and a
32-bit one for ia32 binaries. With the size of each VDSO around 1.5KB, space
becomes really tight in the shared page, which needs space for other stuff as
well, like timehands or random generator seeds.

Build scripts enforce that VDSOs do not grow larger than 2K; if they do, we
need to extend shared page to become at least two shared pages. Scripts also
enforce that VDSO are pure position-independent, not requiring relocations for
either code or metadata (.cfi).

Sponsor: The FreeBSD Foundation

Kernel

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

The AVX bug on amd64

Commit: 73b357be9238 URL: https://cgit.freebsd.org/src/commit/?id=
73b357be92385cbb70ba19e7023a736af2c6b493

Contact: Konstantin Belousov <kib@FreeBSD.org>

Some CPUs support the so called init optimization for XSAVE, but not all CPUs
do. And when they do, 'according to complex internal microarchitectural
conditions', the optimization might happen or not. Basically, this means that
sometimes the CPU does not write all of the state on XSAVE and records in
xstate_bv that it did not.

On signal delivery, the OS provides the saved context interrupted by the signal
to the signal handler. The context includes all CPU state available to
userspace, including FPU registers (XSAVE area). Also, on return from the
signal handler, context is restored, which allows the handler to modify the
main program flow. When init optimization kicks in, the OS tries to hide init
state optimization from the signal handler, by filling non-saved parts of the
XSAVE area.

This is where the problem happens. For states parts 0 (x87) and 1 (SSE/XMM),
Intel CPUs do not provide an enumeration of layout in CPUID, assuming that the
OS knows about the regions anyway. The bug was that the amd64 kernel hardcoded
a 32bit size for the XMM save area, effectively filling %XMM8-%XMM15 with
garbage on signal return when init optimization kicked in, because only
specified part of the SSE save area was copied from the canonical save area.

Sponsor: The FreeBSD Foundation

ENA FreeBSD Driver Update

Links:
ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/
ena/README

Contact: Michal Krawczyk <mk@semihalf.com>
Contact: Dawid Gorecki <dgr@semihalf.com>
Contact: Marcin Wojtas <mw@semihalf.com>

ENA (Elastic Network Adapter) is the smart NIC available in the virtualized
environment of Amazon Web Services (AWS). The ENA driver supports multiple
transmit and receive queues and can handle up to 100 Gb/s of network traffic,
depending on the instance type on which it is used.

Completed since the last update:

• Add IPv6 layer 4 checksum offload support to the driver

• Add NUMA awareness to the driver when the RSS kernel option is enabled

• Rework validation of the Tx request ID

• Change lifetime of the driver’s timer service

• Avoid reset triggering when the device is unresponsive

Work in progress:

• Prototype the driver port to the iflib framework

• Tests of the incoming ENA driver release (v2.5.0)

Sponsor: Amazon.com Inc

Intel Wireless driver support

Links:
iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/Iwlwifi

Contact: Bjoern A. Zeeb <bz@FreeBSD.ORG>

The Intel Wireless driver update project aims to bring support for newer
chipsets along with mac80211 LinuxKPI compat code. The dual-licensed Intel
driver code was ported in the past for the iwm(4) native driver; using the
LinuxKPI compat framework allows us to use the driver directly, with only very
minor modifications that we hope will be incorporated into the original driver.

During December the driver, firmware, and all remaining LinuxKPI compatibility
code were committed to FreeBSD main (HEAD) and merged to the stable/13 branch.
Further fixes, updates, and improvements will go directly into FreeBSD, meaning
the need to apply snapshots is gone and changes can be distributed more timely.

During the last months we tried to ensure that the latest AX210 chipsets are
supported. The compat code was restructured both to be able to better trace and
debug the mac80211 compatibility layer, but also to keep the net80211 and
mac80211 state machines for stations better in sync.

While we keep updating the driver and all the compat code needed for that, the
focus remains on stability and adding support for newer 802.11 standards. The
driver is still set to 11a/b/g-only and 11n will be next before we look at
11ac.

With the code in FreeBSD git we anticipate broader testing and with that also
some fallout. For the latest state of the development, please follow the
referenced wiki page and the freebsd-wireless mailing list.

Sponsor: The FreeBSD Foundation

Kernel Crypto changes to support WireGuard

Contact: John Baldwin <jhb@FreeBSD.org>

During the past few months, I merged several changes to the kernel to better
support the WireGuard driver. These include extensions to the 'struct
enc_xform' interface to better support AEAD ciphers, changes to 'struct
enc_xform' to support multi-block operations for improved performance, and the
addition of the XChaCha20-Poly1305 AEAD cipher suite to OCF. Additionally, the
kernel now includes a new "direct" API for ChaCha20-Poly1305 operations on
small, flat buffers. A change in review adds an API to support curve25519
operations. With these changes, the WireGuard driver is mostly able to use
crypto APIs from the kernel rather than its internal implementations.

In parallel I have been updating the WireGuard driver to use the new APIs
verifying interoperability with the existing driver. One of the next tasks is
to refine these changes (along with some minor bug fixes) as candidates for
upstreaming into the WireGuard driver.

Sponsor: The FreeBSD Foundation

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 URL: https://freebsd.kde.org/
KDE Community FreeBSD URL: https://community.kde.org/FreeBSD

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

The KDE on FreeBSD project aims to package the software from the KDE Community,
along with dependencies and related software, for the FreeBSD ports tree. That
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@ as well, building the software
stack to make FreeBSD beautiful and usable as a daily-driver graphics-based
desktop machine.

• Just two CMake updates this quarter, ending up with CMake 3.22.1. Some more
patches have landed upstream, and CMake is soon to switch to share/man for
manpages on FreeBSD. When it does, there will be plenty of pkg-plist churn.

• Monthly releases of KDE Frameworks, KDE Plasma, and KDE Gear kept the
exp-runs going. kde@ would like to thank Antoine for overseeing our many
exp-run requests. We are now at KDE Frameworks 5.89 (latest release as of
December 2021), KDE Plasma Desktop 5.23.4 and KDE Gear 21.12.

• Qt 5 is not receiving any open source updates from the Qt Company, but the
KDE Community maintains its own set of patches that backport many fixes
from Qt 6. Work is underway to import the KDE patch collection.

• Qt 6 remains tantalizingly close. There hasn’t been real progress on the
crash-on-exit problem, though.

• deskutils/kalendar is a relatively new port that uses KDE technologies for
a desktop (appointments) calendar.

• deskutils/latte-dock, an alternative launcher for KDE Plasma (and other
environments) was updated to each of its bugfix releases.

• devel/qbs and devel/qtcreator were updated. Qbs (or "Qt Build System") is a
declarative build system styled along the lines of declarative QML
programs. (Note that Qbs is not used by Qt itself).

• graphics/digikam was updated to the latest release and now supports both
ImageMagick 6 and ImageMagick 7. Speaking of which, a new USES=magick was
introduced to simplify ports that depend in ImageMagick.

• graphics/ksnip, one of several screenshot-applications for KDE Plasma (and
other environments) had a lots-of-bugfixes update.

• graphics/skanpage is a new port that scans multiple pages and produces a
PDF of the whole.

• multimedia/qt5-multimedia now ignores gstreamer-gl (rather than implicitly
building with it as a dependency if it is installed a build time).

• net-im/ruqola is a Rocket Chat client, updated to the latest release.

• security/qtkeychain has a new release.

Elsewhere in the software stack, kde@ also maintains ports that support the
desktop in general. Some highlights are:

• devel/libphonenumber keeps chasing changes to the world’s phone numbers
(the FreeBSD foundation can be reached at +1.720.207.5142).

• graphics/poppler updated this much-used PDF-rendering library.

• multimedia/pipewire, the audio-and-video successor to pulseaudio, was
updated and now supports SSL as well.

• net/py-pytradfri got several updates so you can control your lights from
FreeBSD.

• print/freetype2 was updated to the latest release; relatedly, there was am
update to x11-toolkits/libXft.

• print/harfbuzz, the text-shaping library, was updated for more font type
support.

• sysutils/bsdisks is an implementation of DBus interfaces for examining
disks (drives, partitions, etc.). It is also used for removable-disk
notifications.

• x11-themes/adwaita-qt, which connects the adwaita theme engine to Qt-based
applications, was updated.

FreeBSD Office Team

Links:
The FreeBSD Office project URL: https://wiki.freebsd.org/Office

Contact: FreeBSD Office team ML <office@FreeBSD.org>
Contact: Dima Panov <fluffy@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>

The FreeBSD Office team works on a number of office-related software suites and
tools such as OpenOffice and LibreOffice.

Work during this quarter was focused on providing the latest stable release of
LibreOffice suite and companion apps to all FreeBSD users.

Latest and quarterly ports branches got a new branch (7.2) of the LibreOffice
suite and updated to the 7.2.4 release while new preleases such as 7.2.5.RC2
and 7.3.0.RC1 are cooking in the WIP stage area.

Meanwhile, our WIP repository got back a working CI instance again, thanks to
Li-Wen Hsu.

Also we are still working on the Boost WIP repository to bring the latest Boost
library to the ports.

We are looking for people to help with the open tasks:

• The open bugs list contains all filed issues which need some attention

• Upstream local patches in ports

Patches, comments and objections are always welcome in the mailing list and
bugzilla.

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.

helloSystem

Links:
Documentation URL: https://hellosystem.github.io/

Contact: Simon Peter <probono@puredarwin.org>
Contact: #helloSystem on irc.libera.chat, mirrored to #helloSystem:matrix.org
on Matrix

What is helloSystem?

helloSystem is FreeBSD preconfigured as a desktop operating system with a focus
on simplicity, elegance, and usability. Its design follows the “Less, but
better” philosophy.

Q4 2021 Status

• Version 0.7.0 of helloSystem has been published including many contributed
features and bugfixes

□ helloSystem is now based on FreeBSD 13.0-RELEASE

□ Completely reworked Live ISO architecture, resulting in 1/3rd boot time
and under 800 MB size (fits a CD-ROM)

□ Developer Tools are now a separate download

□ Disk Images are increasingly used throughout the system, such as for
application distribution and Linuxulator userland deployment

□ Many new features and GUI utilities to make the desktop more usable for
"mere mortals" without the need for a terminal

Installable Live ISO images and a full changelog are available at https://
github.com/helloSystem/ISO/releases/tag/r0.7.0

Contributing

The project appreciates contributions in various areas.

Containers & FreeBSD: Pot, Potluck & Potman

Links:
Pot on github URL: https://github.com/pizzamig/pot
Potluck Repository & Project URL: https://potluck.honeyguide.net/
Potluck on github URL: https://github.com/hny-gd/potluck
Potman on github URL: https://github.com/grembo/potman

Contact: Luca Pizzamiglio (Pot) <pizzamig@freebsd.org>
Contact: Stephan Lichtenauer (Potluck) <sl@honeyguide.eu>
Contact: Michael Gmelin (Potman) <grembo@FreeBSD.org>

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

In the last quarter, a new release 0.14.0 with a number of fixes and features
like the new copy-in-flv command was made available.

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.

Here we again had a busy quarter. All images have been rebuilt for FreeBSD 12.3
and pot 0.13.0.
Also the images that can be used to build a virtual data center like Nomad,
Consul and Vault have received a lot more tender love and care and are
meanwhile in pre-production use on a cluster at a fintech.
Not all these changes have yet been committed to the github repository though,
this is planned for the next quarter. Additionally, new images like
multi-master OpenLDAP have been added, too.

Potman aims to simplify building Pot images with Vagrant and VirtualBox based
on the Potluck approach, e.g. as part of a DevOps workflow for software
development including testing and publishing them to a repository.

Here we have not yet made a lot of headway with our plan to utilise Potman in
the Potluck library build process but this is still on our TODO-list, like
improving the documentation for using the Virtual DC images from the Potluck
library.

As always, feedback and patches are welcome.