FreeBSD Project Quarterly Status Report - Third Quarter 2020

   This report covers FreeBSD related projects for the period between July
   and September, and is the third of four planned reports for 2020.

   This quarter brings a good mix of additions and changes to the FreeBSD
   Project and community, from a diverse number of teams and people
   covering everything from architectures, continuous integration,
   wireless networking and drivers, over drm, desktop and third-party
   project work, as well as several team reports, along with many other
   interesting subjects too numerous to mention.

   As the world is still affected by the epidemic, we hope that this
   report can also serve as a good reminder that there is good work that
   can be done by people working together, even if we're apart.

   We hope you'll be as interested in reading it, as we've been in making
   it. Daniel Ebdrup Jensen, on behalf of the quarterly team.

FreeBSD Team Reports

     * FreeBSD Foundation
     * FreeBSD Release Engineering Team
     * Cluster Administration Team
     * Continuous Integration
     * Ports Collection
     * FreeBSD Office team - 3rd quarter 2020 report
     * FreeBSD Graphics Team status report


     * FreeBSD on Microsoft HyperV and Azure
     * Building FreeBSD on non-FreeBSD hosts
     * Git Migration Working Group
     * Linux compatibility layer update
     * LLDB Debugger Improvements
     * Lua usage in FreeBSD
     * NFS over TLS implementation
     * syzkaller on FreeBSD


     * DRM Drivers Update
     * DTS Update
     * DesignWare Ethernet adapter driver improvements
     * Google Summer of Code'20 Project - eBPF XDP Hooks
     * ENA FreeBSD Driver Update
     * IPSec Extended Sequence Number (ESN) support
     * NXP ARM64 SoC support
     * Addition of PowerPC64LE Architecture
     * ure - USB 3.0 Gigabit Ethernet Driver update
     * Stateless hardware offloads for VXLANs
     * Wireless updates
     * ZSTD Compression in ZFS


     * CheriBSD 2020 Q3
     * FreeBSD/RISC-V Project


     * Update to grub-bhyve
     * KDE on FreeBSD


     * DOCNG on FreeBSD

Third-Party Projects

     * Potluck - Flavour & Image Repository for pot

FreeBSD Team Reports

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

FreeBSD Foundation

   Contact: Deb Goodkin <>

   The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated
   to supporting and promoting the FreeBSD Project and community
   worldwide. Funding comes from individual and corporate donations and is
   used to fund and manage software development projects, conferences and
   developer summits, and provide travel grants to FreeBSD contributors.
   The Foundation purchases and supports hardware to improve and maintain
   FreeBSD infrastructure and provides resources to improve security,
   quality assurance, and release engineering efforts; publishes marketing
   material to promote, educate, and advocate for the FreeBSD Project;
   facilitates collaboration between commercial vendors and FreeBSD
   developers; and finally, represents 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:

COVID-19 Impact to the Foundation

   Like other organizations, we put policies in place for all of our staff
   members to work from home. We also put a temporary ban on travel for
   staff members. We are continuing our work supporting the community and
   Project, but some of our work and responses may be delayed because of
   changes in some of our priorities and the impact of limited childcare
   for a few of our staff members.

Partnerships and Commercial User Support

   We help facilitate collaboration between commercial users and FreeBSD
   developers. We also meet with companies to discuss their needs and
   bring that information back to the Project. Not surprisingly, the stay
   at home orders, combined with our company ban on travel during Q3 made
   in-person meetings non-existent. However, the team was able to continue
   meeting with our partners and commercial users virtually. These
   meetings help us understand some of the applications where FreeBSD is

   We are currently scheduling Zoom company meetings for Q4, please reach
   out if you would like to schedule a meeting with us.

Fundraising Efforts

   Last quarter we raised $192,874.43! Thank you to the individuals and
   organizations that stepped in, to help fund our efforts. We'd like to
   thank Arm for their large contribution last quarter, which helped bring
   our 2020 fundraising effort to $521k. We hope other organizations will
   follow their lead and give back to help us continue supporting FreeBSD.

   These are trying times, and we deeply appreciate every donation that
   has come in from $5 to $150,000. We're still here giving 110% to
   supporting FreeBSD!

   We are 100% funded by donations, and those funds go towards software
   development work to improve FreeBSD, FreeBSD advocacy around the world,
   keeping FreeBSD secure, continuous integration improvements, sponsoring
   BSD-related and computing conferences (even the virtual events!), legal
   support for the Project, and many other areas.

   Please consider making a donation to help us continue and increase our
   support for FreeBSD.

   We also have the Partnership Program, to provide more benefits for our
   larger commercial donors. Find out more information about the
   partnership program and share with your companies!

OS Improvements

   A number of FreeBSD Foundation grant recipients started, continued
   working on, or completed projects during the third quarter. These
     * Ongoing WiFi and Linux KPI layer improvements.
     * Linuxulator application compatibility.
     * DRM / Graphics driver updates.
     * Zstd compression for OpenZFS.
     * Online RAID-Z expansion.
     * Modernized LLDB target support for FreeBSD.

   You can find more details about most of these projects in other


   Staff members also worked on a number of larger projects, including:
     * Run-Time Dynamic Linker (rtld) and kernel ELF loader improvements.
     * Rewritten UNIX domain socket locking.
     * Build infrastructure.
     * Open system call path handling support for O_BENEATH,
     * arm64 support.
     * Migration to a Git repository.

   Many of these projects also have detailed entries in other quarterly


   Staff members also put in significant effort in many ways other than
   larger, individual projects. These include assisting with code reviews,
   bug report triage, security report triage and advisory handling,
   addressing syzkaller reports, and ongoing maintenance and bug fixes in
   functional areas such as the tool chain, developer tools, virtual
   memory kernel subsystem, low-level x86 infrastructure, sockets and
   protocols, and others.

University of Waterloo Co-op

   With the transition to working from home, the Foundation decided to
   again take on three University of Waterloo Co-op students for the Fall
   2020 term (September to December). Tiger returns for a second term,
   joined by new students Yang and Zac. Projects for the term include more
   work on ELF Tool Chain, application of Capsicum to additional
   utilities, testing and integration of FreePBX and Asterisk VOIP
   software, pkgbase, and exploring containerization tooling.

Continuous Integration and Quality Assurance

   The Foundation provides a full-time staff member and funds projects on
   improving continuous integration, automated testing, and overall
   quality assurance efforts for the FreeBSD project.

   During the third quarter of 2020, Foundation staff continued improving
   and monitoring the Project's CI infrastructure, and working with
   experts to fix the failing builds and the regressions found by tests.
   The setting up of dedicated VM host for running tests is completed. New
   feature developments and the CI staging environment is in progress. We
   are also working with other teams in the Project for their testing
   needs. For example, tests of non-x86 architectures now run
   periodically, and improve the CI of the embedded systems. We are also
   working with many external projects and companies to improve the CI
   between their products and FreeBSD.

   See the FreeBSD CI section of this report for completed work items and
   detailed information.

Supporting FreeBSD Infrastructure

   The Foundation provides hardware and support to improve the FreeBSD
   infrastructure. Last quarter, we continued supporting FreeBSD hardware
   located around the world. We coordinated efforts between the new NYI
   Chicago facility and clusteradm to start working on getting the
   facility prepared for some of the new FreeBSD hardware we are planning
   on purchasing. NYI generously provides this for free to the Project. We
   also worked on connecting with the new owners of the Bridgewater site,
   where most of the FreeBSD infrastructure is located.

   Some of the purchases we made for the Project last quarter to support
   infrastructure includes:
     * Spamhaus spam filtering software to limit the amount of spam on the
       mailing lists.
     * 5 application servers to run tasks like bugzilla, wiki, website,
       cgi, Phabricator, host git, etc.
     * 1 server to replace the old pkg server and provide a lot more IOPS
       to avoid the slowdowns seen during peak times of the day where the
       disks just cannot keep up with the request volume.
     * 1 server for exp-runs to make them faster.
     * 1 server to build packages more frequently.

FreeBSD Advocacy and Education

   A large part of our efforts are dedicated to advocating for the
   Project. This includes promoting work being done by others with
   FreeBSD; producing advocacy literature to teach people about FreeBSD
   and help make the path to starting using FreeBSD or contributing to the
   Project easier; and attending and getting other FreeBSD contributors to
   volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD

   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, to work together on projects, and to facilitate
   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. As is the case for most of us in this industry, COVID-19 has
   put our in-person events on hold. In addition to attending virtual
   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 last quarter:
     * Launched our FreeBSD Fridays series of 101 classes. Topics included
       an Introduction to FreeBSD, FreeBSD Installfest, Introduction to
       Security, Introduction to ZFS and more. Videos of the past sessions
       and a schedule of upcoming events can be found here.
     * Attended and presented at OSI's State of the Source conference. The
       event was held virtually, September 9-11, 2020.
     * Launched the redesign of the FreeBSD Foundation Website.
     * Announced the 20th Anniversary of the FreeBSD Foundation.
     * Participated as an Admin for Google Summer of Code 2020
     * Continued to promote the FreeBSD Office Hours series including
       holding our own Foundation led office hours. Videos from the one
       hour sessions can be found on the Project's YouTube Channel. You
       can watch ours here.
     * Interviewed members of the outgoing FreeBSD Core Team to get their
       thoughts on their term.
     * Began working with the FreeBSD Vendor Summit planning committee on
       the November 2020 Vendor Summit.
     * Promoted the Foundation's 20th Anniversary and our work to support
       the FreeBSD Project in the It's FOSS Article. FreeBSD Foundation
       Celebrates 20 Years of Promoting and Supporting FreeBSD Project.
     * Authored a Beginners Guide to FreeBSD for Fosslife.
     * Committed to sponsoring All Things Open as a media Sponsor.
     * Committed to sponsoring the OpenZFS Developers Summit at the Bronze
     * Became an International RISC-V Member.
     * Committed to giving a FreeBSD talk at the conference on
       October 20th.

   Keep up to date with our latest work in our

   monthly newsletters.

   Netflix provided an update on how and why they use FreeBSD in our
   latest Contributor Case Study.

   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

   You can find out more about events we attended and upcoming events at

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. We updated our Trademark
   Usage Terms and Conditions on July 1, 2020.

   Go to the FreeBSD Foundation's web site to find out how we support
   FreeBSD and how we can help you!

   ### Other

   We welcomed Andrew Wafaa and Kevin Bowling to our board of directors,
   to help govern the Foundation and guide us with our strategic
   direction. We have more information about our new board members on our

FreeBSD Release Engineering Team

   FreeBSD 12.2-RELEASE schedule 
   FreeBSD 12.2 test builds 
   FreeBSD development snapshots 

   Contact: FreeBSD Release Engineering Team <>

   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 third quarter of 2020, the Release Engineering Team started
   work on the 12.2-RELEASE cycle, the third release from the stable/12

   As of this writing, two BETA builds have been released, with the
   expectation there will be a third BETA build currently remaining on the

   The 12.2-RELEASE cycle will continue throughout October, with two RC
   builds currently planned, and RC3 scheduled on an as-needed basis. The
   12.2-RELEASE is so far scheduled for final release on October 27.

   In addition to the 12.2-RELEASE, Glen Barber of the Release Engineering
   Team finished work to the release build tools and scripts to prepare
   for the conversion from Subversion to Git for the 13.0-RELEASE cycle.
   There are no plans to merge these changes to stable branches at this
   time; as discussed within the Git working group, we feel such a change
   on a stable branch would be too intrusive to our user base as well as
   downstream FreeBSD consumers. Development snapshot builds for
   13.0-CURRENT have recently been built from the Git tree within the
   project, and further snapshot builds for 12.x and 11.x will continue to
   be built from Subversion.

   Additionally throughout the quarter, several development snapshots
   builds were released for the head, stable/12, and stable/11 branches.

   Finally, the Release Engineering Team would like to thank Marius Strobl
   for his time serving on the team; he had recently stepped down from the
   Deputy RE Lead role due to constraints on his time. The Team welcomes
   Colin Percival, who has accepted fulfilling this role.

   Much of this work was sponsored by Rubicon Communications, LLC
   ( and the FreeBSD Foundation.

Cluster Administration Team

   Cluster Administration Team members 

   Contact: Cluster Administration Team <>

   The FreeBSD Cluster Administration Team consists of the people
   responsible for administering the machines that the Project relies on
   for its distributed work and communications to be synchronised. In this
   quarter, the team has worked on the following:
     * Work with the FreeBSD Foundation on hardware update for web
       services, mirror and package building servers.
     * Disable directory indexing on the package mirrors to resolve
       performance issues of the machine.
          + This was later relaxed to allow indexing of the parent
            directories but still disallow the large package directories.
     * Ongoing systems administration work:
          + Accounts management for committers.
          + Backups of critical infrastructure.
          + Keeping up with security updates in 3rd party software.

   Work in progress:
     * Setup Malaysia (KUL) mirror.
     * Setup Brazil (BRA) mirror.
     * Review the service jails and service administrators operation.
     * Infrastructure of building aarch64 and powerpc64 packages.
          + NVMe issues on PowerPC64 POWER9 blocking dual socket machine
            from being used as pkg builder.
          + Drive upgrade test for pkg builders (SSDs) courtesy of the
            FreeBSD Foundation.
          + Boot issues with Aarch64 reference machines.
     * New sponsored colocation space in Chicago-land area.
     * Work with git working group for the git repository.
     * Searching for more providers that can fit the requirements for a
       generic mirrored layout or a tiny mirror.

Continuous Integration

   FreeBSD Jenkins Instance 
   FreeBSD Hardware Testing Lab 
   FreeBSD CI artifact archive 
   FreeBSD CI weekly report 
   FreeBSD Jenkins wiki 
   Hosted CI wiki 
   3rd Party Software CI 
   Tickets related to freebsd-testing@ 
   FreeBSD CI Repository 

   Contact: Jenkins Admin <>
   Contact: Li-Wen Hsu <>

   Contact: freebsd-testing Mailing List
   Contact: IRC #freebsd-ci channel on EFNet

   The FreeBSD CI team maintains the continuous integration system of the
   FreeBSD project. The CI system firstly checks the committed changes can
   be successfully built, then performs various tests and analysis over
   the newly built results. The artifacts from those builds are archived
   in the artifact server for further testing and debugging needs. The CI
   team members examine the failing builds and unstable tests and work
   with the experts in that area to fix the codes or adjust test
   infrastructure. The details of these efforts are available in the
   weekly CI reports.

   During the third quarter of 2020, we continued working with the
   contributors and developers in the project to fulfill their testing
   needs and also keep collaborating with external projects and companies
   to improve their products and FreeBSD.

   Important changes:
     * All !x86 -test builds now trigger a new build on 22:00 UTC daily;
       this was not running very often because running all the tests in
       qemu takes lots of time. The work on improving the test execution
       speed and parallelism is in progress. The following is a list of
       the jobs affected:
          + Test build for FreeBSD HEAD on ARMv7.
          + Test build for FreeBSD HEAD on AArch64.
          + Test build for FreeBSD HEAD on MIPS64.
          + Test build for FreeBSD HEAD on PowerPC64.
          + Test build for FreeBSD HEAD on RISC-V64.
     * The build and test results will be sent to the dev-ci mailing list
       soon. Feedback and help with analysis is very appreciated!
          + A builder dedicated to run jobs using provisioned VMs is
            setup, this improves the stableness and reduces the execution
          + The result of FreeBSD-head-amd64-test_zfs is changed after
            OpenZFS importing; we encourage everyone to check and fix the
            failing and skipped test cases.

   New jobs added:
     * CI build for FreeBSD HEAD on PowerPC64LE.

   Work in progress:
     * Collecting and sorting CI tasks and ideas here.
     * Testing and merging pull requests in the the FreeBSD-ci repo.
     * Designing and implementing pre-commit CI building and testing,
     * Reduce the procedures of CI/test environment setting up for
       contributors and developers.
     * Setting up the CI stage environment and putting the experimental
       jobs on it.
     * Setting up public network access for the VM guest running tests.
     * Implementing automatic tests on bare metal hardware.
     * Adding drm ports building tests against -CURRENT.
     * Planning to run ztest and network stack tests.
     * Adding more external toolchain related jobs.
     * Improving the hardware lab to be more mature and adding more
     * Helping more 3rd software get CI on FreeBSD through a hosted CI
     * Working with hosted CI providers to have better FreeBSD support.

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

   Sponsor: The FreeBSD Foundation

Ports Collection

   About FreeBSD Ports 
   Contributing to Ports 
   FreeBSD Ports Monitoring 
   Ports Management Team 

   Contact: René Ladan <>
   Contact: FreeBSD Ports Management Team <>

   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 passed the landmark of 40,000 ports in the Ports Collection and are
   now around 40,400 ports. The last quarter saw 9335 commits to the HEAD
   branch and 481 commits to the 2020Q3 branch by respectively 167 and 63
   committers. There are currently 2525 open problem reports of which 595
   are unassigned. Compared to last quarter, this means a slight decrease
   in activity and also a slight increase in open PRs.

   During the last quarter we welcomed Rainer Hurling (rhurlin@) and said
   goodbye to Kevin Lo (kevlo@) and Grzegorz Blach (gblach@).

   The last three months saw new default versions for Perl (5.32),
   PostgreSQL (12) and PHP (7.4). Various packages also got updated:
   Firefox to 81.0.1, Chromium to 84.0.4147.135, Gnome to 3.36, Xorg to
   1.20.9, Qt5 to 5.15.0, Emacs to 27.1, KDE Frameworks to 5.74.0 and pkg
   itself to 1.15.8.

   Never tired, antoine@ ran 30 exp-runs to test port version updates, on
   such diverse matters as:
     * Updating byacc in base to 20200330.
     * Check balancing of sed "y" command.
     * Use of brackets.
     * Removing the now redundant "port" argument from USES=readline.

FreeBSD Office team - 3rd quarter 2020 report

   The FreeBSD Office project 

   Contact: FreeBSD Office team ML <>
   Contact: Dima Panov <>
   Contact: Li-Wen Hsu <>

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

   Work during this quarter focused on providing the latest stable release
   of LibreOffice suite and companion apps to all FreeBSD users.
     * Alongside with updating old stable branch to latest 6.4.x releases,
       current ports-tree now have a full-featured cutting-edge 7.0.1
     * Conservative users can keep 6.4.x stable version by switching to
       use all-in-one editors/libreoffice6 port and even with i18n
       language pack (off by default). It will be kept updated at least
       till 7.1.0 version is released.

   We are looking for people to help the project.

   All unstable work with LibreOffice snapshots is staged in our WIP
   The open bugs list contains all filed issues which need some attention.
   Patches, comments and objections are always welcome in the mailing list
   and bugzilla.

FreeBSD Graphics Team status report

   Project GitHub page 

   Contact: FreeBSD Graphics Team <>
   Contact: Niclas Zeising <>

   The FreeBSD X11/Graphics team maintains the lower levels of the FreeBSD
   graphics stack. This includes graphics drivers, graphics libraries such
   as the MESA OpenGL implementation, the xserver with related
   libraries and applications, and Wayland with related libraries and

   There have been several updates to the FreeBSD graphics stack and
   related libraries since the last report.

   Most notably, MESA related ports were changed to use the meson build
   system, instead of the autotools based one. This was needed since mesa
   upstream has deprecated and removed the autotools build system, and
   this paved the way for further mesa updates. While there was a need for
   a few minor corrections after the initial update, this update has been
   successful and made it possible to further update and improve the
   FreeBSD mesa port.

   There have also been several security fixes for xorg-server and libX11,
   so these ports have been updated to fix these issues.

   During the period, FreeBSD 12 was changed to improve the compatibility
   with input devices using udev/evdev and libinput. This change removes
   the need for local configuration and makes most mice, touchpads and
   keyboards work out of the box. This change will be in the upcoming
   FreeBSD 12.2 release.

   There have also been several updates to various libraries, both in the
   graphics and input stacks, and several userland drivers have been
   updated. Libraries such as libdrm and libevdev have been updated to
   include new FreeBSD support, developed by team members and added

   There has also been ongoing work to keep the various drm-kmod ports and
   packages up to date, mostly in response to changes in various FreeBSD

   We have also continued our regularly scheduled bi-weekly meetings.

   People who are interested in helping out can find us on the mailing list, or on our gitter chat. We are also
   available in #freebsd-xorg on EFNet.

   We also have a team area on GitHub where our work repositories can be


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

   FreeBSD on Microsoft HyperV and Azure

   Microsoft Azure article on FreeBSD wiki  
   Microsoft HyperV article on FreeBSD wiki 

   Contact: FreeBSD Integration Services Team <>
   Contact: Wei Hu <>
   Contact: Li-Wen Hsu <>

   Li-Wen is working on the FreeBSD release code related to Azure for the
   -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is
   available here. The 11.4-RELEASE image on Azure Marketplace is
   published. We are testing the releng/12.2 branch and 12.2-RELEASE image
   will be published to Azure Marketplace soon after released.

   This project is sponsored by The FreeBSD Foundation, with resources
   provided by Microsoft.

Building FreeBSD on non-FreeBSD hosts


   Contact: Alex Richardson <>

   Until recently FreeBSD could only be built on a FreeBSD host. However,
   many popular free CI tools only allow building on Linux or macOS and
   therefore can not be used for building the FreeBSD base system.
   Furthermore, it is sometimes useful to cross-build FreeBSD for a remote
   machine or an emulator even if the build machine is not running
   FreeBSD. The goal of this project is to allow building the base system
   on Linux and macOS hosts.

   I started this project in 2017 to allow building CheriBSD on the Linux
   servers and desktops that many of us working on the CHERI project use.
   The first few patches were upstreamed in 2018 (see the 2018q3 report)
   and I merged the full set of patches to CheriBSD shortly after. Over
   the past two years I have slowly been upstreaming the remaining patches
   and finally committed the last required change in time for this report.

   As of September 2020 it should be possible to use the buildworld and
   buildkernel make targets to build a fully-functional FreeBSD
   installation on macOS and Linux hosts. We use this in our continuous
   integration system to build and test CheriBSD disk images for multiple
   architectures. I have also committed a GitHub Actions configuration
   upstream that takes approximately 10 minutes to build an amd64 kernel.
   This will ensure that changes that break crossbuilding from Linux/macOS
   can be detected easily.

   Upstreaming the crossbuilding changes has resulted in various build
   system cleanups. For example, we now no longer need to use
   when building libraries which speeds up the linking step a bit. The
   portability and bootstrapping changes should also make it easier to
   upgrade from older versions since we no longer rely on host headers in
   /usr/include matching those of the target system (e.g. when
   bootstrapping localedef, etc.).

   While this support for building on Linux and macOS should still be
   considered experimental, it should work in many cases. If you would
   like to give it a try, the following command line should successfully
   build an amd64 world on Linux and macOS systems that have packages for
   LLVM 10 (or newer) installed: MAKEOBJDIRPREFIX=/somewhere
   ./tools/build/ TARGET=amd64 TARGET_ARCH=amd64 buildworld Builds
   must be performed using the ./tools/build/ wrapper script since
   most Linux and macOS systems do not ship an appropriate version of
   bmake. Please let me know if you encounter any issues.

   Sponsor: DARPA

Git Migration Working Group

   Git conversion tooling repo 
   FreeBSD-git mailing list 
   Beta doc git repo 
   Beta ports git repo 
   Beta src git repo 

   Contact: Ed Maste <>
   Contact: Warner Losh <>
   Contact: Ulrich Spörlein <>

   Work continues on FreeBSD's migration from Subversion to Git. Ulrich
   has addressed all known issues with svn2git and has been able to work
   around the inconsistent metadata and forced commit issues in the
   Subversion history.

   We still have additional documentation to write, and need to finish
   installing commit hooks (e.g. restricting branch creation, or ensuring
   appropriate data exists on cherry-pick commits).

   We expect to open the beta repository to test commits before the end of
   October. This is to allow testing of the commit hooks, and to allow
   developers to test access and become familiar with git operation.
   Commits in this repository will be deleted and the repository will be
   recreated at least once prior to the final migration.

   Those with an interest in the migration to Git are encouraged to
   subscribe to the FreeBSD-git mailing list and test out the beta src,
   ports, and/or doc repositories.

   You are also welcome check out the wiki, issues, README and other
   documentation at the Git conversion tooling repo.

   We currently expect to transition the src and doc repositories in
   mid-November. Additional investigation and experimentation with the
   ports repository is still underway.

   Sponsor: The FreeBSD Foundation (in part)

Linux compatibility layer update

   Contact: Edward Tomasz Napierala <>
   Contact: Mark Johnston <>

   Earlier Linuxulator work focused on code cleanups and improving
   diagnostic tools. Work has now shifted from cleanups to fixing actual
   applications. Current status is being tracked at Linux app status Wiki
   page. Initial focus was on applications that don't involve X11, mostly
   because they tend to be easier to test and debug, and the bug fixes are
   not application-specific.

   Foundation-sponsored work during this quarter included implementing a
   devfs(5) workaround to fix gettynam(3) inside jail/chroot, and
   workaround for the missing splice(2) syscall, which caused problems for
   grep and autotools. The Linux version reported to userspace was bumped
   to 3.10.0, which matches the kernel shipped with RHEL 7 and is
   neccessary for IBM's DB2 database installation to succeed. The
   BLKPBSZGET ioctl neccessary for Oracle database is supported now. There
   is now support for kcov(4), neccessary for syzcaller; as well as a
   number of fixes for issues reported by syzcaller, such as futex lock
   leaks. There were also more cleanups, including moving some
   Linuxulator-specific functionality related to error handling off from
   the syscall's fast code paths. The sysutils/debootstrap port, which
   provides an easy way to create Debian or Ubuntu jail, was updated to
   version 1.0.123. Finally there were some improvements to the

   Most of those changes have been merged to FreeBSD 12-STABLE, in order
   to ship with 12.2-RELEASE.

   There is increased involvement from other developers; this includes
   termios performance fixes, improved memfd support, implementing
   CLOCK_MONOTONIC_RAW required for Steam, madvise improvements, new
   compat.linux.use_emul_path sysctl. There is also ongoing work on
   tracking down the causes of failures related to Steam and WebKit, with
   fixes being first implemented in linuxulator-steam-utils.

   Sponsor: The FreeBSD Foundation

LLDB Debugger Improvements

   Moritz Systems Project Description 
   Git Repository 

   Contact: Kamil Rytarowski <>
   Contact: Michal Górny <>

   FreeBSD includes LLDB, the debugger in the LLVM family, in the base
   system. At present it has some limitations in comparison with the GNU
   GDB debugger, and does not yet provide a complete replacement. It
   relies on an obsolete plugin model in LLDB that causes growing
   technical debt. This project aims to bring LLDB closer to a fully
   featured replacement for GDB, and therefore for FreeBSD to feature a
   modern debugger for software developers.

   The legacy monolithic target supports the executed application being
   debugged in the same process space as the debugger. The modern LLDB
   plugin approach, used on other supported targets, executes the target
   process under a separate lldb-server process. This improves reliability
   and simplifies the process / thread model in LLDB itself. In addition,
   remote and local debugging will both be performed using the same

   After the migration to the new process model is complete, the project
   will include reviewing the results of LLDB's test suite and fixing
   tests as time permits. The work is expected to be complete in 2020.

   The project schedule is divided into three milestones, each taking
   approximately one month:

   1. Introduce new FreeBSD Remote Process Plugin for x86_64 with basic
   support and upstream to LLVM. 2. Ensure and add the mandated features
   in the project (process launch, process attach (pid), process attach
   (name), userland core files, breakpoints, watchpoints, threads, remote
   debugging) for FreeBSD/amd64 and FreeBSD/i386. 3. Iterate over the LLDB
   tests. Detect, and as time permits, fix bugs. Ensure bug reports for
   each non-fixed and known problem. Add missing man pages and update the
   FreeBSD Handbook.

   We are nearing the completion of the first milestone. The new plugin is
   getting into shape, and it can already run simple single-threaded
   programs. The supported features include single-stepping, breakpoints,
   memory and register I/O on amd64. Both plugins are supported
   simultaneously. The new plugin is used if FREEBSD_REMOTE_PLUGIN
   environment variable is set to any value, or if lldb-server is spawned
   directly. Otherwise, the old plugin is used for compatibility. Once the
   new plugin matures, we are planning to enable it unconditionally on the
   architectures that it is ported to.

   Sponsor: The FreeBSD Foundation

Lua usage in FreeBSD

   Contact: Ed Maste <>
   Contact: Kyle Evans <>
   Contact: Ryan Moeller <>

   During this quarter, flua (FreeBSD Lua) was taught where to find base
   .lua modules in order to support require of .lua modules to be provided
   by the base system. flua also gained support for require of binary

   A review for libjail bindings has also been submitted, pending review.
   libjail is an essential component if one wants to be able to write jail
   management utilities in flua.

   People interested in working with Lua in FreeBSD are welcome to get in
   contact to discuss other project ideas. To name a couple of potential
   projects, some interesting modules that have not been started but could
   prove useful (listed in no particular order):
     * libcrypt
     * libexpat
     * libnv
     * libxo

   There is also a small list of scripts that would do well with a port to
     * certctl(8)

NFS over TLS implementation

   Contact: Rick Macklem <>

   In an effort to improve NFS security, an internet draft which I expect
   will become an RFC soon specifies the use of TLS 1.3 to encrypt all
   data traffic on a Sun RPC connection used for NFS.

   Although NFS has been able to use sec=krb5p to encrypt data on the
   wire, this requires a Kerberos environment and, as such, has not been
   widely adopted. It also required that encryption/decryption be done in
   software, since only the RPC message NFS arguments are encrypted. Since
   Kernel TLS is capable of using hardware assist to improve performance
   and does not require Kerberos, NFS over TLS may be more widely adopted,
   once implementations are available.

   The coding for this project has now been completed. All required
   changes to the NFS and kernel RPC code have been committed to -CURRENT.
   The daemons are now believed to be complete, but will remain in
   base/projects/nfs-over-tls until -CURRENT has an OpenSSL library with
   the kernel TLS support incorporated in it. If this does not happen for
   FreeBSD-13, hopefully the patched OpenSSL and the daemons can become

   To support clients such as laptops, the daemons that perform the TLS
   handshake may optionally handle client X.509 certificates from a site
   local CA. There are now exports(5) options to require client(s) to
   provide a valid X.509 certificate.

   While setting up system(s) for testing is still a little awkward, the
   documentation is now available for those who want to help with testing.

   The main limitation in the current implementation is that it uses
   TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch
   includes TLS1.3 support.

   Third party testing would be appreciated.

syzkaller on FreeBSD

   Contact: Mark Johnston <>

   See the syzkaller entry in the 2019q1 quarterly report for an
   introduction to syzkaller.

   syzkaller, especially the public syzbot instance, continues to find
   bugs in the FreeBSD kernel. A number of these bugs have been fixed in
   subsystems such as the VFS name cache, the TCP and SCTP stacks, pf(4),
   the unix domain socket implementation, and the Linuxulator.

   The FreeBSD Foundation sponsored some work to enable cross-OS fuzzing.
   This makes it possible to fuzz the Linuxulator using syzkaller's Linux
   target. This effort quickly found several bugs; once the support is
   committed upstream we will hopefully be able to leverage syzbot to gain
   continuous testing of the Linux system call interface in addition to
   the native and 32-bit compatibility interfaces.

   Some work was also done to enable running syzkaller in a FreeBSD jail,
   with the eventual aim of making it easy to distribute binary images
   containing everything required to immediately start running syzkaller
   on a new host. Currently a number of setup steps are required, making
   deployment somewhat painful.

   Sponsor: The FreeBSD Foundation


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

DRM Drivers Update


   Contact: Emmanuel Vadot <>

   The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux
   5.4.62 Then graphics/drm-current-kmod have been updated to follow this
   LTS release of Linux.

   For now graphics/drm-devel-kmod is also tracking this release but will
   be updated to a later revision of Linux drm drivers in the near future.

   A lot of linuxkpi code was removed from the ports or replaced with a
   BSD licenced implementation.

   Sponsor: The FreeBSD Foundation

DTS Update

   Contact: Emmanuel Vadot <>

   DTS files (Device Tree Sources) were updated to be on par with Linux
   5.8 for HEAD and 5.6 for the 12-STABLE branch.

DesignWare Ethernet adapter driver improvements

   WIP branch 

   Contact: Oleksandr Tymoshenko <>

   DesignWare Ethernet adapter IP is used in Rockchip and Allwinner SoCs.
   The driver was updated with following fixes:
     * Initialize clocks instead of relying on u-boot to do the right
     * Sense media type and adjust controller configuration accordingly.
     * Add support for RMII PHY mode.

   Yet uncommitted changes include performance optimisation by adding

   support for multi-segment mbuf transmission. The next step is to try to
   get more performance boost by using interrupt coalescence.

Google Summer of Code'20 Project - eBPF XDP Hooks

   Github diff link 
   Project wiki     

   Contact: Ankur Kothiwal <>

   The eBPF eXpress Data Path (XDP) allows eBPF programs to be run to
   filter received packets as early as possible, avoiding unnecessary
   processing overhead before the filter is run. The goal of this project
   is to extend an existing FreeBSD network driver (a virtual NIC like a
   VirtIO if_vtnet) to be able to call into an eBPF program when
   processing a newly received packet. In short, with XDP the driver must
   PASS (accept and process normally), DROP, TX or REDIRECT the packet as
   specified by the program. eBPF helper functions and maps for aiding in
   packet filtering will also be implemented.

     * Register a eBPF probe when an interface is registered with pfil.
     * Activating eBPF probe.
     * Create hooks and link them to the pfil head when the eBPF XDP probe
       is activated and successfully list the XDP probes.
     * Create a xdp_rx function which will pass the received packets to
       the eBPF program where the packets can be further processed. This
       function will return XDP actions: DROP and PASS.
     * Register the xdp hook and link it to the pfil head.
     * Write an eBPF program to process (currently drop and pass) ICMP
       traffic - This is to test that the hook is working properly.
     * Write a loader function to load the ICMP filter program to the

   Future Work:
     * Currently we can only attach the XDP hook to PASS and DROP the
       packets - The work on detaching the hook is left.
     * The XDP action to "TX" and "REDIRECT" the packets.

   Final Deliverables:
     * Implemented XDP hook to pass and drop packets.
     * Created a loader program to attach the eBPF program to the kernel.
     * A test program to DROP ICMP filter.

   This code was done under the Google Summer of Code 2020 under the

   of Ryan Stone (rstone@). The eBPF implementation for FreeBSD is still a
   work in progress and FreeBSD doesn't support eBPF yet. The basic
   implementation for eBPF was a GSoC'18 project, and is still under
   development. This project is based on that implementation so the XDP
   implementation for FreeBSD can only be merged into the FreeBSD source
   code once it supports eBPF.

   Currently this code is a work in progress and is merged to Ryan Stone's
   branch with support for the eBPF implementation.

   Sponsor: Google Summer of Code

ENA FreeBSD Driver Update


   Contact: Michal Krawczyk <>
   Contact: Artur Rojek <>
   Contact: Marcin Wojtas <>

   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

   Completed since the last update:
     * Fix ENA compilation in case it is integrated into the kernel
     * MFC of the ENA v2.2.0 driver to the FreeBSD 12.2.

   Work in progress:
     * Add feature that allows reading extra ENI (Elastic Network
       Interface) metrics about exceeding BW/pps limits.
     * Introduce full kernel RSS API support.
     * Allow reconfiguration of the RSS indirection table and hash key.
     * Evaluation and prototyping of the driver port to the iflib

   Sponsor: Inc

IPSec Extended Sequence Number (ESN) support

   Contact: Grzegorz Jaszczyk <>
   Contact: Patryk Duda <>
   Contact: Marcin Wojtas <>

   Extended Sequence Number (ESN) is IPSec extension defined in RFC4303
   Section 2.2.1. It makes possible to implement high-speed IPSec
   implementations where standard, 32-bit sequence number is not
   sufficient. A key feature of the ESN is that only low order 32 bits of
   sequence number are transmitted over the wire. High-order 32 bits are
   maintained by sender and receiver. Additionally high-order bits are
   included in the computation of Integrity Check Value (ICV) field.

   Extended Sequence Number support contains following:
     * Modification of existing anti-replay algorithm to fulfil ESN
     * Trigger soft lifetime expiration at 80% of UINT32_MAX when ESN is
     * Implement support for including ESN into ICV in cryptosoft engine
       in both encrypt and authenticate mode (eg. AES-CBC and SHA256 HMAC)
       and combined mode (eg. AES-GCM).
     * Implement support for including ESN into ICV in AES-NI engine in
       both encrypt and authenticate mode and combined mode.

   Completed since the last update:
     * Adjust implementation of crypto part to the reworked Open Crypto
     * Move the core ESN implementation from the crypto drivers to
       netipsec layer.
     * Make use of the newly introduced crp_aad mechanism for combined
     * Introduce minor fixes and improvements.

     * Complete review process in Phabricator and merge patches in the

   Sponsor: Stormshield

NXP ARM64 SoC support

   Contact: Marcin Wojtas <>
   Contact: Artur Rojek <>
   Contact: Dawid Gorecki <>

   The Semihalf team initiated working on FreeBSD support for the NXP
   LS1046A SoC

   LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with
   integrated packet processing acceleration and high speed peripherals
   including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide
   range of networking, storage, security and industrial applications.

   Completed since the last update:
     * Upstreaming of the QorIQ SDHCI driver (r365054).

   With above the current Semihalf upstreaming activity is complete.

   The major out-of-tree supported components:
     * DPAA network controller support.
     * QSPI controller support.

   They work on 11.2-RELEASE, but still require significant

   effort to adopt to FreeBSD-CURRENT.

   Sponsor: Alstom Group

Addition of PowerPC64LE Architecture

   Early notes 

   Contact: Brandon Bergren <>

   As of r366063, experimental support for little-endian PowerPC64
   (PowerPC64LE) is available in -CURRENT for POWER8 and POWER9 machines.

   In 2010, when FreeBSD was ported to PowerPC64, the average user would
   have been using a G5 PowerMac, a purely big-endian machine.

   While, at the time, a 32-bit PowerPC machine could run in
   little-endian, as well as POWER6 and POWER7, in practice, the
   complexities involved in managing it at the kernel level and lack of
   firmware support made it infeasible to support.

   When IBM designed POWER8, one main focus was to improve little-endian
   support, and bring it up to parity with big-endian.

   This improved support makes it practical to support a little-endian
   operating environment on what is traditionally a primarily big-endian

   In 2020, with POWER9 being affordable for many users thanks to the
   Raptor Blackbird, semi-easy access to surplus POWER8 hardware, IBM
   having a major future focus on POWER little-endian, and the decay of
   big-endian support in modern video cards and graphical environments,
   there is demand for a little-endian version of FreeBSD on POWER.

   With FreeBSD/PowerPC64's transition in 2019 to the ELFv2 ABI as part of
   the 2019q4 PowerPC on Clang effort, the last major barrier to a
   little-endian port was eliminated.

   Since nobody else was working on it, and I had the skillset required to
   do the port, I decided to experiment one weekend with a little-endian
   kernel to see how difficult it would be to port.

   It turned out to be a lot more trivial than I was expecting. Three days
   later I had console support in qemu, and after another week of
   debugging, I had it fully up and running on hardware.

   FreeBSD PowerPC64LE is now an experimental MACHINE_ARCH in base, and is
   continuing to evolve at a rapid pace.

   Big-endian PowerPC64 is still the preferred platform for the
   foreseeable future, and will not be deprecated.

   Sponsor: Tag1 Consulting, Inc.

ure - USB 3.0 Gigabit Ethernet Driver update

   svn commit: r365648 
   D25809 major update to if_ure 

   Contact: John-Mark Gurney <>

   The ure is a driver for handling the RealTek ethernet adapters,
   including the RTL8153 USB 3.0 Gigabit ethernet adapters. It is used in
   many ethernet dongles and docking stations.

   Previous to this update, the driver was limited in speed. In my
   testing, I was only able to get ~91Mbps. This limit was due to one
   packet per USB transfer. USB has a limit of 8000 transfers per second
   (1500 bytes/pkt * 8000 pkts/sec * 8bits/byte == 96 Mbps). This was
   acceptable for fast ethernet (RTL8152, 100Mbps), but with the
   additional support for Gigabit ethernet, it became a bottleneck.

   The updates add sending and receiving multiple packets in a single USB
   transfer, VLAN hardware tagging, and enable TCP and UDP checksum
   offloading. This increased the speed on gigabit ethernet to ~940 Mbps.

   In doing this work, a security vulnerability was discovered in the
   driver. Due to improper setting of a device register, on some devices,
   it caused packets to be fragmented when they shouldn't be and the
   driver was unable to handle them correctly. This allowed an attacker,
   who could generate large frames (say, ping packets, or large TCP
   transfers), to inject arbitrary packets into the network stack. This
   could allow the attacker to spoof traffic from other machines, and
   bypass VLAN protections. See the SA for more information.

   As part of this work, a script was created to run tests to validate
   that basic functionality of the driver (w/o options) work properly, and
   then iterate over each option to make sure that they function properly.
   This will be released at some point in the future.

   If you're interested in helping out, or testing it, let me know.

Stateless hardware offloads for VXLANs


   Contact: Navdeep Parhar <>

   VXLAN (Virtual eXtensible LAN) is a tunneling protocol in which Layer 2
   traffic for a virtual LAN is encapsulated in UDP and transferred over
   Layer 3 networks between VTEPs (VXLAN Tunnel End Points). Traffic on
   the wire has two sets of networking headers: the headers for the
   encapsulation and the headers of the traffic being encapsulated. VXLANs
   are supported by if_vxlan(4) on FreeBSD.

   Modern NICs commonly support header checksum insertion and
   verification, TSO (TCP Segmentation Offload) on transmit, and RSS for
   load distribution on receive. But the default is to operate on the
   outermost headers. Some NICs can operate on the inner encapsulated
   frames as well. The commits listed above allow if_vxlan(4) to take
   advantage of such NICs.

   r365867 and r365868 add new mbuf checksum flags and ifnet capabilities.
   r365870 implements the kernel parts of the new capabilities and updates
   if_vxlan(4) to make use of them. r365871 implements driver support for
   the new capabilities in cxgbe(4).

   VXLAN and other tunneling protocols that use UDP explicitly allow zero
   checksum in the outer UDP header, even with IPv6. r365869 adds support
   for configuring one UDP/IPv6 port where zero checksums are allowed.

   This work was sponsored by Chelsio Communications and was implemented
   and tested using T6 (Terminator 6) NICs supported by cxgbe(4). It is
   available in 13.0-CURRENT (head) right now and will be available in
   12-STABLE in the future.

   VXLANs can be created as usual and will automatically have checksum and
   TSO capabilities if the underlying physical interface supports VXLAN
   stateless offloads. Use ifconfig to list, disable, and enable checksum
   capabilities on the VXLAN interface. Use to report bugs.

   Future work:
     * Direct call into a vxlan input routine from the driver's receive
     * LRO support in if_vxlan(4).
     * GENEVE support.

   Sponsor: Chelsio Communications

Wireless updates

   The freebsd-wireless mailing list 
   athp github repository 

   Contact: Adrian Chadd <>
   Contact: Bjoern A. Zeeb <>

   The following works happened in FreeBSD HEAD (some already in Q2) and
   were merged for 12.2-BETA2 and include net80211 and driver updates for
   better 11n and upcoming 11ac support.

   In more detail, this includes an ath(4) update, some run(4) 11n
   support, 11n for otus(4), A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames
   options, scanning fixes, enhanced PRIV checks for jails, restored
   parent device name printing, improvements for upcoming VHT support,
   lots of under-the-hood infrastructure improvements, new device IDs, and
   debug tools updates.

   If you have a chance please test before the release.

Atheros 11ac driver athp

   In the last three months the athp(4) port of the ath10k driver has
   progressed well. Adrian reports the following important changes:
     * Per-node transmit buffering was implemented, required for correct
       hostap and QCA6174 behaviour.
     * Issues with ignoring sending some management frames got fixed;
       null-data frames were being filtered out and this caused
       undesirable hostap behaviour.
     * Transmit path refactoring reduced code duplication.
     * A fix on firmware start / VAP running tracking no longer stops the
       first VAP from coming active after VAP creation / ifconfig up.
     * Correcting hostap mode PHY configuration now allows non-VHT
       stations to associate and correctly exchange data with a VHT AP.
     * Addition of a crypto key configuration cache in the driver ensures
       the ieee80211_key details are available after the key is deleted;
       net80211 would reuse or free the state before the driver task would
       finish the firmware command.

Newer Intel Wireless device support

   Initial work was done to integrate net80211 support in the LinuxKPI
   compat layer to get the wireless parts going. In addition, upstreaming
   code changes and working through problems and review started on two
   sides. One was trying to get mostly compile time changes upstreamed to
   the iwlwifi driver. The other is sorting out conflicting LinuxKPI
   changes to not break the DRM graphics drivers. Bjoern hopes that with
   some of that sorted out, he can soon go back to focus on the wireless
   parts and produce a new snapshot.

rtw88 and brcmfmac

   As the Intel driver port and LinuxKPI advance, both the rtw88, and to a
   lower degree the brcmfmac, ports benefit from that. Bjoern lately also
   got a brcmfmac PCIe card and started to port support for that. This for
   the moment remains a free-time project.

   Work by Bjoern was sponsored by: Rubicon Communications, LLC (d/b/a
   "Netgate") and The FreeBSD Foundation

ZSTD Compression in ZFS

   Contact: Allan Jude <>

   Zstandard (ZSTD) is a modern high-performance compression algorithm
   designed to provide the compression ratios of gzip while offering much
   better performance. ZSTD has been adopted in FreeBSD for a number of
   other uses, including compressing kernel crash dumps, as a replacement
   for gzip or bzip for compressing log files, and for future versions of

   This effort to complete the integration of ZSTD into ZFS is funded by
   the FreeBSD Foundation.

   During the third quarter the integrating of ZSTD into OpenZFS was
   completed in the upstream OpenZFS repository, and the new OpenZFS 2.0
   codebase was imported into 13-CURRENT. Completed milestones in this
     * Importing ZSTD 1.4.5 into OpenZFS, using the recent upstream zstd
       features that make it easier to embed zstd in other projects.
     * Changing the way compression levels are tracked and inherited.
     * Save and restore the compression level via an embedded block
     * Also store the version of zstd used in the embedded block header,
       for future-proofing. The checksum of a block may not match if zstd
       is upgraded, since it may compress the block more.
     * Add tests to ensure zstd compression and metadata survive ZFS
     * Resolve possible negative interactions with L2ARC and ZFS Native
     * Fix bug with L2ARC if the Compressed ARC feature is disabled.
     * Improve the ZFS feature activation code, so that zstd cannot create
       pools that will panic older versions of ZFS.

   With these changes, upgraded pools can compress data with zstd

   or zstd-fast, across a wide range of different compression levels. This
   will allow the storage administrator to select the
   performance-vs-compression tradeoff that best suits their needs.

   Tasks remaining to be completed:
     * Add a section to the FreeBSD Handbook ZFS chapter about zstd
     * Create more documentation around selecting a suitable compression
     * Finish support for ZSTD in the FreeBSD boot loader (Warner Losh

   Sponsor: The FreeBSD Foundation


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

CheriBSD 2020 Q3


   Contact: Alex Richardson <>
   Contact: Andrew Turner <>
   Contact: Brooks Davis <>
   Contact: Edward Tomasz Napierala <>
   Contact: George Neville-Neil <>
   Contact: Jessica Clarke <>
   Contact: John Baldwin <>
   Contact: Robert Watson <>
   Contact: Ruslan Bukin <>

   CheriBSD extends FreeBSD to implement memory protection and software
   compartmentalization features supported by the CHERI instruction-set
   extensions. There are three architectural implementations of the CHERI
   protection model: CHERI-MIPS, CHERI-RISC-V, and Arm's forthcoming
   experimental Morello processor (due late 2021). CheriBSD is a research
   operating system with a stable baseline implementation into which
   various new research features have been, or are currently being,
     * Arm Morello - We are preparing to open source our adaptation of
       CheriBSD to Arm's Morello architecture. The Morello branch is being
       updated to the most recent CheriBSD baseline, and patches are in
       review for upstreaming to our open-source repository. CheriBSD
       currently boots and runs statically linked CheriABI binaries on the
       Morello simulator, and dynamic linking support is in progress, with
       OS and toolchain bugs being worked on. We aim to make a first
       CheriBSD/Morello snapshot available alongside other open-source
       Morello software in mid-October 2020, however, our target for a
       more mature and usable implementation is December 2020.
     * Kernel spatial memory safety (pure-capability kernel) - The current
       CheriBSD kernel is a hybrid C program where only pointers to
       userspace are CHERI capabilities. This ensures that the kernel
       follows the intent of the application runtime and cannot be used to
       defeat bounds on application pointers. We have developed and will
       soon merge a pure-capability kernel where all pointers in the
       kernel are appropriately bounded capabilities. This vastly reduces
       the opportunity for buffer overflows. This spatial memory safety
       lays the groundwork for future work such as device driver
       compartmentalization and kernel temporal safety.
     * Userspace heap temporal memory safety (Cornucopia) - CHERI
       capabilities provide the necessary features to enable robust and
       efficient revocation of freed pointers. With Cornucopia we have
       implemented a light-weight revocation framework providing
       protection from use-after-reallocation bugs with an average cost
       below 2%. We aim to bring these overheads down further over the
       next year and merge this functionality into the mainline CheriBSD.
     * We have been working on updating the arm64 bhyve from Politehnica
       University of Bucharest to have it committed to FreeBSD. We have
       been upstreaming initial changes to help support this.
     * Baseline FreeBSD improvements - We are upstreaming (to FreeBSD)
       various bug fixes and tweaks for PCIe support, and support for the
       System MMU (SMMU) that will be present on the N1SDP and Morello
       SoCs. We have upstreamed support for cross-building FreeBSD from
       macOS and Linux (with some limitations; see separate entry on
       crossbuilding). We have also fixed implementation bugs in the
       RISC-V ABI.

CHERI Documentation and Exercises

     * We have released [Capability Hardware Enhanced RISC Instructions:
       CHERI Instruction-Set Architecture (Version
       Notable changes include promotion of CHERI-RISC-V to
       non-experimental and discussion of Arm's Morello prototype.
     * We have developed a set of [Adversarial CHERI Exercises and
       Missions]( to
       introduce security researchers to CHERI protections.

FreeBSD/RISC-V Project


   Contact: Mitchell Horne <>

   Contact: freebsd-riscv Mailing List
   Contact: IRC #freebsd-riscv on freenode

   The FreeBSD/RISC-V project is providing support for running FreeBSD on
   the RISC-V Instruction Set Architecture.

   This quarter saw several important bug fixes. A number of hangs in the
   system were identified and addressed, and a bug in QEMU's
   implementation of the Platform Level Interrupt Controller was fixed.
   This fix is included in the new devel/qemu50 and devel/qemu-devel

   The end result of these fixes is that the test suite can now be
   reliably run to completion in QEMU. The entire run takes several hours,
   so CI has been configured to run the job once a day. There is active
   effort into reducing the time it takes to run the entire test suite.

   A new u-boot port was created: sysutils/u-boot-qemu-riscv64. This
   variant can be used as a secondary bootloader alongside OpenSBI to load
   and launch FreeBSD's loader(8) from an EFI System Partition.

   Next quarter will likely bring further fixes to address some of the
   failing test cases.


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

Update to grub-bhyve

   grub-bhyve Git Repository 

   Contact: Chuck Tuffli <>

   bhyve is the hypervisor included in FreeBSD and other operating systems
   used to run virtual machines. When not using a boot ROM (i.e. UEFI),
   the user must load the guest operating system for bhyve. For
   non-FreeBSD guests, the loader is a version of GNU GRUB (a.k.a the GNU
   GRand Unified Bootloader) modified to interface with bhyve. This work
   is an effort to both update the base GRUB code to the latest version as
   well as improve the usability on FreeBSD.

   The current grub-bhyve is based on an older version of GRUB (circa
   2015) and thus is missing more recent additions such as XFS file system
   and syslinux support. With the update, installing CentOS, for example,
   now does not require the extra step of changing the default file system
   to something other than XFS.

   Internally, the code has been restructured to be its own "platform"
   which should make it easier to keep in sync with upstream development.
   The major improvement is the ability to automatically find and load the
   GRUB configuration file from the guest disk image. With this change, it
   is not necessary to create a device map file or specify which Linux
   kernel or initrd image to use. More importantly, if the guest image
   updates its GRUB configuration, for example after updating the kernel,
   no changes are needed when invoking grub-bhyve. Note, this feature
   requires a new "disk" option:

   # grub-bhyve --disk=/zroot/vms/u18-mini/disk0.img --vm=u18-mini

   The automatic configuration file detection works with both GRUB
   configuration files (e.g. CentOS, Ubuntu) as well as syslinux
   configuration (e.g. Alpine). For the adventurous, there is experimental
   support for Fedora's BootLoaderSpec (a.k.a. blscfg) on the blscfg
   branch of the grub-bhyve Git repository.

   The code has been tested on a few Linux variants, but it would benefit
   from wider testing (and bug reports!). The new version does not have a
   Port but is easily built on FreeBSD. After cloning / downloading the
   source, run:

   $ PYTHON=python3.7 ./bootstrap $ MAKE=gmake ./configure
   --with-platform=bhyve $ gmake

   The resulting binary, grub-bhyve, will be in the grub-core/ directory.
   If you have success or troubles with it, please let me know.

KDE on FreeBSD

   KDE FreeBSD           
   KDE Community FreeBSD 

   Contact: Adriaan de Groot <>

   The KDE on FreeBSD project aims to package all of the software produced
   by the KDE Community for the FreeBSD ports tree. The software includes
   a full desktop environment called KDE Plasma, an IDE with the name
   KDevelop, a PIM suite known as Kontact and hundreds of other
   applications that can be used on any FreeBSD machine.

   With the continuation of the ever-so-peculiar era of
   almost-only-online, the KDE community has shifted gears and also gone
   for online events. The yearly conference, Akademy, was conducted online
   over video calls. Meanwhile, software continues to be released, so this
   quarter the kde@ team:
     * Put the beta of the next version of KDE Plasma, scheduled for
       official release in October 2020, into the Area51 development tree.
       Area51 is a fork of the FreeBSD ports tree where new development
       for KDE ports happens.
     * The monthly regular updates to the KDE Plasma desktop landed
       on-time and safely.
     * With three months in a quarter, there were also three releases of
       KDE Frameworks 5, including a new framework for handling DAV jobs.
     * The June applications update and its .1 release landed a bit late,
       but brings with it the usual raft of updates to KDE applications
       and libraries,
     * A new Digikam release, which arrived in the ports tree on the day
       of its release.
     * A new KDevelop release arrived a day after its release. This update
       contains a number of crash fixes for refactoring support.
     * Qt was updated to Qt 5.15, the last in the Qt5 series and an LTS
       version. Bugfix releases are expected, but the next major Qt will
       be Qt 6.

   On the infrastructure front, August saw some minor updates to CMake and

   As usual, kde@ continues to support the work of xorg@ and gnome@ in
   maintaining the Free Desktop stack on FreeBSD, including XOrg, poppler,
   and xdg-utils. A new MAINTAINER group, desktop@, has been created to
   provide shared ownership of that shared stack.

   With Python2 deprecation looming, the build system for QtWebEngine --
   itself a fork of Chromium -- is becoming a pressing issue in Q4 and
   will no doubt chew up a lot of time in the coming months.


   Noteworthy changes in the documentation tree, in manpages, or in
   external books/documents.


   DOCNG Website Repo 
   DOCNG Documentation Repo 
   DOCNG Share Repo 

   Contact: Sergio Carlavilla <>

   The Doc New Generation project aims to convert the website and all
   existing documentation to Hugo/AsciiDoctor. Right now almost everything
   is converted as you can see in the repositories.

   The objective of using Hugo and AsciiDoctor is to reduce the learning
   curve and let people to start quickly with our documentation system.
   Other benefits of using Hugo is that we can use other technologies
   aside from AsciiDoctor, like MarkDown, RST, Pandoc, etc.

   The remaining tasks include:
     * Finish the conversion of some books to AsciiDoctor.
     * Get some tweaks in the CSS to be responsive.
     * Add AsciiDoctor extensions to create an index of tables and
     * Make a general review.

   The dates for making the migration have yet to be discussed.

   Patches, comments and objections are always welcome.

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

Potluck - Flavour & Image Repository for pot

   Potluck Repository & Project 
   Potluck on github            
   pot project                  

   Contact: <>

   pot is a jail management tool that also supports orchestration through

   Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and
   Docker: A repository of pot flavours and complete images for usage with

   In the last quarter, an initial set of Nomad, Consul and Traefik images
   has been created that are sufficient to run a simple virtual datacenter
   out of the box.
   A three-part article series explaining how to set this up is also
   available now.

   Furthermore, ready-made images suitable for scheduling via Nomad and
   Consul in such an environment have been created, e.g. a BackupPC or a
   Postfix Backup MX service.

   Future plans include additional images and exposing more configuration
   options in the existing images to allow a more flexible usage.

   Beside general feedback and tests, additional flavours and patches are
   very welcome!

   Sponsors: Honeyguide GmbH & Honeyguide Group (Pty) Ltd ## Puppet
   Puppet Puppet's FreeBSD slack channel Bolt Choria Puppet Team

   Since out last status report a few years ago, the puppet@ team
   regularly updated the various Puppet ports to follow upstream releases
   of Puppet 4, Puppet 5 and Puppet 6. Puppet 4 was removed when it
   reached EOL.

   More recently, an effort was made to enhance Facter 4 so that it can be
   used as a drop-in replacement of Facter 3 on FreeBSD. Facter 4 is a
   Ruby rewrite of Facter 3, the C++ rewrite of Facter 2 which was
   initially in Ruby. As a consequence we have two ports for Facter:
   sysutils/facter is the C++ implementation (Facter 3) and
   sysutils/rubygems-facter is the Ruby implementation (updated from
   Facter 2 to Facter 4 a few weeks ago). The Puppet 5 and Puppet 6 ports
   already allow to choose which version of Facter to use. Facter 4 will
   be the default version of Facter with Puppet 7 which is expected to be
   released soon.

   We are getting ready to add a port for Puppet 7 as sysutils/puppet7
   when it is available, along with PuppetServer 7
   (sysutils/puppetserver7), and PuppetDB 7 (databases/puppetdb7).

   Regarding orchestration, most Marionette Collective ports have been
   deprecated for a long time, and the last component sysutils/mcollective
   is expected to be deprecated soon: Marionette Collective was not
   shipped anymore with Puppet 6 and Bolt has been made available as a
   lightweight replacement.

   Bolt is already available in the ports tree as sysutils/rubygems-bolt),
   but if you are using Marionette Collective, you are invited to look
   into Choria which will reach the ports tree soon as sysutils/choria.
   Choria is a direct evolution of Marionette Collective allowing a smooth
   transition from MCollective. Once Choria is available in the ports
   tree, Marionette Collective will be deprecated.

   News Home | Status Home
   Site Map | Legal Notices | © 1995-2020 The FreeBSD Project. All rights

Attachment: signature.asc
Description: PGP signature

Reply via email to