Without subscribers, LWN would simply not exist. Please consider
signing up for a subscription and helping
to keep LWN publishing
June 21, 2019
This article was contributed by Sean Kerner
The FreeBSD operating system is continuing
to make progress, 26 years after it got its name. Among the areas where
work is being done is on
improved support for RISC-V, FUSE
filesystem updates, C runtime changes, and security improvements. FreeBSD
Day is celebrated on June 19, in recognition of the date in 1993 when
the name FreeBSD was coined for
a fork of the 386BSD project. The first official release
of FreeBSD did not occur until November 1, 1993, however.
Ahead of FreeBSD
Day, the project released its quarterly
report for the first quarter of 2019, outlining some of its ongoing
efforts. In addition to the quarterly report, the executive director of the
FreeBSD Foundation provided LWN with some insights into the state of the
project and the foundation that supports it.
System architecture
Just as is the case with Linux, system architecture support is a
constant ongoing area of development and improvement in FreeBSD. One of
the newer architectures that developers are working on
is RISC-V; multiple new capabilities have been
added for that processor. Last year, LWN covered
RISC-V and its support on Linux. RISC-V is a growing effort that has
the support of 235 member organizations of the RISC-V Foundation, which
got started in 2015.
For RISC-V, FreeBSD has recently added
support for large page mapping for memory and per-CPU pmap
activation tracking. From the man page:
“The pmap module is responsible for managing hardware-dependent
objects such as page tables, address maps, TLBs, etc.“. The quarterly
report notes that the work “noticeably improves the responsiveness of
FreeBSD when
running in a multi-CPU virtual machine.”
Debugging support for
RISC-V on FreeBSD is also making progress with the completion of a RISC-V
implementation of minidumps, which
is the default type of kernel crash dump, providing the contents of memory
pages that are being used by the kernel. There is still work that
needs to
be done for debugging RISC-V with the GNU Debugger (GDB),
which is the default tool used in FreeBSD. According to the
report, “support for debugging RISC-V kernel dumps will
land in devel/gdb after the next GDB release.”
In addition, C runtime changes have been made to improve the handling of
thread-local storage (TLS):
The FreeBSD dynamic linker was fixed to properly distribute TLS
initialization data to all threads’ initial segments, which required
reasonably extensive per-architecture changes to libc and libthr. LLD was improved to mark
libraries using initial exec TLS mode with the appropriate flag. These
measures should make FreeBSD more resilient to improperly linked libraries.
Support for Broadcom ARM64 systems-on-chip (SoCs), specifically the
BCM5871X SoC series is
currently in progress for FreeBSD, with completed work expected to be
merged in the second half of 2019. The quarterly report noted that
“BCM5871X are quad-core 64-bit ARMv8 Cortex-A57 communication
processors
targeted for networking applications such as 10G routers, gateways, control
plane processing and NAS.” The work to enable support for the
BCM5871X is being sponsored by Juniper Networks, which makes use of FreeBSD
as the base for its own Junos
OS operating system for networking equipment.
Also of note is the fact that documentation for running
FreeBSD on Apple’s older Mac Mini hardware models shipped from 2007 to 2014
has been updated, enabling new life for the older systems. Moving forward,
the goal is to have more information for installation support, including
the 2018 Mac mini model. “There are now detailed instructions for
installing FreeBSD as the only operating system on models from 2007 through
2014 and itemised model specific information detailing FreeBSD support,
” the report said.
Linux tools in FreeBSD
While
there is no shortage of tools that are unique to FreeBSD, there are also a
number of tools that have come over from Linux. One such tool is the
syzkaller coverage-guided system-call fuzzer, which LWN reported on when it began to
take shape back in 2016. The report described some of the work:
Recently, a number of
FreeBSD developers have been using syzkaller to find and fix bugs in the
FreeBSD kernel. […] Work is ongoing to improve syzkaller’s coverage of
FreeBSD’s
system calls. In particular, syzkaller needs to be taught about all of the
target kernel’s entry points and argument types in order to be useful. Many
of the standard POSIX system calls are already covered, but most
FreeBSD-specific system calls are not.
Work is also ongoing to enable better performance of syzkaller in
FreeBSD. The challenge is that currently syzkaller can run on a FreeBSD
virtual machine (VM) but only via QEMU, which does not have
hardware-acceleration support on FreeBSD. So running a syzkaller VM on a
FreeBSD host does not perform as well as it could.
To fix that issue, work is
progressing to
add support for the bhyve hypervisor
developed by FreeBSD, which will provide the hardware-acceleration
capabilities.
Another technology that is familiar to some Linux users is Filesystem in Userspace
(FUSE) which will be getting much needed attention this year in
FreeBSD. FUSE enables a user-space program to implement a filesystem and is
often used to support out-of-tree filesystems.
FreeBSD’s fuse driver was added as a GSoC project in
2012. Since that time, it has been largely neglected. The FUSE software is
buggy and out-of-date. Our implementation is about 11 years behind.
In recent months, developers have been working to bring the FreeBSD
FUSE driver up to date, fixing existing bugs and raising the driver’s API
support level to a more modern status.
Security
Boot security is also an area that developers have been working on in the
project. Trusted
Platform Module (TPM) 2.0 support has been added, bringing FreeBSD up
to date with the hardware security standard. Secure boot for Unified
Extensible Firmware
Interface (UEFI) systems benefits from a new integration that FreeBSD
developers have been working on. Secure boot support was merged with
veriexec file-signing support, creating a new library named
libsecureboot. The quarterly report explained:
This library is used for verification of kernel and modules by the
loader. The library uses BearSSL as the cryptographic backend. The library
supports loading trusted and blacklist certificates from UEFI (DB/DBx
databases) and can use them as trust anchors for the verification.
The library is also used by Veriexec to verify and parse the authentication
database (called ‘manifest’) in the kernel. Previously the manifest was
verified and parsed by a userspace application, then sent to the kernel via
/dev/veriexec, which was a significant limitation and a security weakness.
FreeBSD merged a patch to implement
Address Space Layout Randomization (ASLR) in the first quarter. ASLR is
used as a way to
randomize the memory locations for executables, in an effort to help limit
memory-based attacks. As to why ASLR is now being added, the
report noted:
While debate continues about the current and forward-looking value ASLR
provides, having an implementation in the FreeBSD source tree makes it
easily available to those who wish to use it. This also moves the
conversation past the relative merits to more comprehensive security
controls.
FreeBSD Foundation
Though FreeBSD as a project is turning 26 this year, the FreeBSD
Foundation got started in March 2000 with a mission to support the
project. Deb Goodkin was hired as the foundation’s first employee in 2005
and has led the organization as its executive director ever since. “At
that time we had a very small budget and have grown to an operational
budget of over $1,250,000,” she told LWN. “The largest change is bringing
on a staff of people to handle FreeBSD advocacy and software development
and fund more outside software development projects.”
The FreeBSD Foundation is a non-profit organization that is funded by
individual and corporate donations. So far in 2019, the foundation has
received support and commitments from NetApp, Netflix, Intel,
Tarsnap, Beckhoff Automation, E-Card, VMware, Stormshield, and
others. According to the quarterly report, the plan is to
continue to have commercial users that give back to help support FreeBSD.
Goodkin said that almost all of the work that the foundation does directly
impacts development. She explained that having staff developers step in and
work on things allows changes to happen quickly, especially when there
isn’t a volunteer on the project willing or available.
Foundation staff also participate in a few of the working groups within the
project,
where they can provide guidance and input on improvements. For example, she
noted that Ed Maste, director of
project development at the foundation is in charge of the Git working
group, which is evaluating whether to move the project from Subversion to
Git for
software revision control. Maste delivered a presentation
[PDF]
at the FreeBSD Vendor Summit in 2018 outlining the areas where Git use
can be a fit, including potentially making a future decision on using Git as
the primary version-control system for the project.
In Goodkin’s view, the most exciting work the foundation is doing right
now is the FreeBSD advocacy and education efforts around the world. Those
efforts include teaching and creating curriculum for workshops on getting
started with FreeBSD, as well as promoting FreeBSD at open-source and
computing conferences. She said that it’s exciting because the
outreach efforts are introducing more people to FreeBSD with the goal of
recruiting more users and contributors to the project.
As FreeBSD marks its 26th anniversary, Goodkin is optimistic about the
project’s future.
“Over the next 25 years, I see FreeBSD becoming a more well-known and
popular operating system, with more people and organizations recognizing
and valuing the reliability, security, and performance that FreeBSD offers
as a compelling solution for a variety of applications,” she said.
Overall it’s clear that after 26 years of development, FreeBSD development
is still active, with improvements to bring older code up to date,
support new architectures like RISC-V, and work
throughout the project that aim to keep the effort vibrant for years to
come.
(Log in to post comments)
