Date: Tue, 4 Jun 2019 14:03:40 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@freebsd.org> To: hackers@freebsd.org Cc: current@freebsd.org, stable@freebsd.org Subject: FreeBSD Quarterly Status Report - First Quarter 2019 Message-ID: <20190604130340.GA2359@v2>
next in thread | raw e-mail | index | archive | help
--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
FreeBSD Project Quarterly Status Report - 1st Quarter 2019
As spring leads into summer, we reflect back on what the FreeBSD
project has accomplished in the first quarter of 2019. Events included
FOSDEM and AsiaBSDCon, the FreeBSD Journal is now free to everyone,
ASLR is available in -CURRENT and KPTI can be controlled per-process.
The run up to 11.3-RELEASE has begun, and a team is applying syzkaller
guided fuzzing to the kernel, plus so much more. Catch up on many new
and ongoing efforts throughout the project, and find where you can
pitch in.
__________________________________________________________________
FreeBSD Team Reports
* Continuous Integration
* FreeBSD Core Team
* FreeBSD Foundation
* FreeBSD Release Engineering Team
* Ports Collection
Projects
* AXP803 PMIC driver update
* Broadcom ARM64 SoC support
* C Runtime changes
* Capsicum
* CFT - Package Base
* ENA FreeBSD Driver Update
* FreeBSD boot security improvements
* FUSE
* Kernel ZLIB Update
* LLVM's lld as the FreeBSD system linker
* mlx5 Drivers Update
* PCI Express Resets
* Security-Related changes
Architectures
* FreeBSD/RISC-V Update
Ports
* FreeBSD GNOME status report
* FreeBSD KDE status report
Third-Party Projects
* FreeBSD Wiki Apple Intel Mac mini update
* Fuzzing FreeBSD with syzkaller
* sysctlmibinfo API 1.0
* sysctlview 1.0
* University of Waterloo Co-operative Education Students
__________________________________________________________________
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in
the Administration Page.
Continuous Integration
Links
FreeBSD Jenkins Instance
URL: https://ci.FreeBSD.org
FreeBSD CI artifact archive
URL: https://artifact.ci.FreeBSD.org/
FreeBSD Jenkins wiki
URL: https://wiki.freebsd.org/Jenkins
freebsd-testing Mailing List
URL: https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing
freebsd-ci Repository
URL: https://github.com/freebsd/freebsd-ci
Tickets related to freebsd-testing@
URL: https://preview.tinyurl.com/y9maauwg
Hosted CI wiki
URL: https://wiki.freebsd.org/HostedCI
FreeBSD CI weekly report
URL: https://hackfoldr.org/freebsd-ci-report/
Contact: Jenkins Admin <jenkins-admin@FreeBSD.org>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
The FreeBSD CI team maintains continuous integration system and related
tasks for the FreeBSD project. The CI system regularly checks the
changes committed to the project's Subversion repository can be
successfully built, and performs various tests and analysis of the
results. The results from build jobs are archived in an artifact
server, for the 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 code or adjust test infrastructure.
Starting from this quarter, we started to publish CI weekly report at
freebsd-testing@ mailing list. The archive is available at
https://hackfoldr.org/freebsd-ci-report/
We also worked on extending test executing environment to improve the
code coverage, temporarily disabling flakey test cases, and opening
tickets to work with domain experts. The details are of these efforts
are available in the weekly CI reports.
We published the draft FCP for CI policy and are ready to accept
comments.
Please see freebsd-testing@ related tickets for more information.
Work in progress:
* Fixing the failing test cases and builds
* Adding drm ports building test against -CURRENT
* Implementing automatic tests on bare metal hardware
* Implementing the embedded testbed
* Planning for running ztest and network stack tests
* Help more 3rd software get CI on FreeBSD through a hosted CI
solution
__________________________________________________________________
FreeBSD Core Team
Contact: FreeBSD Core Team <core@FreeBSD.org>
The FreeBSD Core Team is the governing body of FreeBSD.
Core initiated a Release Engineering Charter Modernization working
group. The purpose of the working group is to present (to Core) a
modernized version of the Release Engineering Charter and a first
version of a new Release Engineering Team Operations Plan. The group
hopes to complete its goals and dissolve by 2019-06-30.
The Core Team invites all members of the FreeBSD community to complete
the 2019 FreeBSD Community Survey.
https://www.research.net/r/freebsd2019
The purpose of the survey is to collect quantitative data from the
public in order to help guide the project's priorities and efforts. It
will remain open for 17 days and close at midnight May 13 UTC (Monday
5pm PDT). (Editor's note: Survey has finished)
Core voted to approve source commit bits for Johannes Lundberg
(johalun@) and Mitchell Horne (mhorne@) and associate membership for
Philip Jocks. Core also voted to revoke Michael Dexter's documentation
bit.
After a long lapse of not closing idle source commit bits, core has
taken in the commit bit for these developers. We thank each for
contributing to the project as a source committer.
* Alfred Perlstein (alfred@)
* Eric Badger (badger@)
* Daniel Eischen (deischen@)
* Ermal Lu=E7i (eri@)
* Tony Finch (fanf@)
* Justin T. Gibbs (gibbs@)
* Imre Vad=E1sz (ivadasz@)
* Julio Merino (jmmv@)
* John W. De Boskey (jwd@)
* Kai Wang (kaiw@)
* Luigi Rizzo (luigi@)
* Neel Natu (neel@)
* Craig Rodrigues (rodrigc@)
* Stanislav Sedov (stas@)
* Thomas Quinot (thomas@)
* Andrew Thompson (thompsa@)
* Pyun YongHyeon (yongari@)
* Zbigniew Bodek (zbb@)
__________________________________________________________________
FreeBSD Foundation
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. 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:
We kicked off the year with an all-day board meeting in Berkeley, where
FreeBSD began, to put together high-level plans for 2019. This included
prioritizing technologies and features we should support, long-term
planning for the next 2-5 years, and philosophical discussions on our
purpose and goals.
Partnerships and Commercial User Support
We began the year by meeting with a few commercial users, to help them
navigate working with the Project, and understanding how they are using
FreeBSD. We're also in the process of setting up meetings for Q2 and
throughout the rest of 2019. Because we're a 501(c)(3) non-profit, we
don't directly support commercial users. However, these meetings allow
us to focus on facilitating collaboration with the community.
Fundraising Efforts
Our work is 100% funded by your donations. We kicked off the year with
many individual and corporate donations, including donations and
commitments from NetApp, Netflix, Intel, Tarsnap, Beckhoff Automation,
E-Card, VMware, and Stormshield. We are working hard to get more
commercial users to give back to help us continue our work supporting
FreeBSD. Please consider making a donation to help us continue and
increase our support for FreeBSD at: www.FreeBSDfoundation.org/donate/.
We also have the Partnership Program, to provide more benefits for our
larger commercial donors. Find out more information at
https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/
and share with your companies!
OS Improvements
The Foundation improves the FreeBSD operating system by employing our
technical staff to maintain and improve critical kernel subsystems, add
features and functionality, and fix problems. This also includes
funding separate project grants like the arm64 port, porting the
blacklistd access control daemon, and the integration of VIMAGE
support, to make sure that FreeBSD remains a viable solution for
research, education, computing, products and more.
Over the quarter there were 241 commits from nine Foundation-sponsored
staff members and grant recipients.
We kicked off or continued the following projects last quarter:
* FUSE file system kernel support (update and bug fixes)
* Linuxulator testing and diagnostics improvements
* SDIO and WiFi infrastructure improvements
* x86-64 scalability and performance improvements
* OpenZFS Online RAID-Z Expansion
Having software developers on staff has allowed us to jump in and work
directly on projects to improve FreeBSD like:
* amd64 and i386 pmap improvements and bugfixes
* address userland threading library issues
* improve i386 support to keep the platform viable
* improve FreeBSD on RISC-V
* application of the Capsicum sandboxing framework
* build system improvements and bug fixes
* respond to reports of security issues
* implement vulnerability mitigations
* tool chain updates and improvements
* adding kernel code coverage support for the Syzkaller
coverage-guided system call fuzzer
* improved Syzkaller support for FreeBSD
* improve the usability of freebsd-update
* improve network stack stability and address race conditions
* ensure FreeBSD provides userland interfaces required by
contemporary applications
* implement support for machine-dependent optimized subroutines
* update and correct documentation and manpages
* DTrace bug fixes
* update the FreeBSD Valgrind port and try to upstream the changes
Continuous Integration and Quality Assurance
The Foundation provides a full-time staff member who is working on
improving our automated testing, continuous integration, and overall
quality assurance efforts.
During the first quarter of 2019, Foundation staff continued improving
the project's CI infrastructure, working with contributors to fix
failing build and test cases, and working with other teams in the
project for their testing needs. In this quarter, we started publishing
the CI weekly report on the freebsd-testing@ mailing list.
See the FreeBSD CI section of this report for more information.
Release Engineering
The Foundation provides a full-time staff member to oversee the release
engineering efforts. This has provided timely and reliable releases
over the last five years.
During the first quarter of 2019, the FreeBSD Release Engineering team
continued providing weekly development snapshots for 13-CURRENT,
12-STABLE, and 11-STABLE.
In addition, the Release Engineering team published the schedule for
the upcoming 11.3-RELEASE cycle, the fourth release from the stable/11
branch, which builds on the stability and reliability of 11.2-RELEASE.
The upcoming 11.3-RELEASE schedule can be found at:
https://www.freebsd.org/releases/11.3R/schedule.html
FreeBSD 11.3 is currently targeted for final release in early July
2019.
Please see the FreeBSD Release Engineering Team section of this
quarterly status report for additional details surrounding the above
mentioned work.
Supporting FreeBSD Infrastructure
The Foundation provides hardware and support to improve FreeBSD
infrastructure. Last quarter, we continued supporting FreeBSD hardware
located around the world.
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
presentations.
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.
Check out some of the advocacy and education work we did last quarter:
* Attended FOSDEM 2019 where we: staffed the FreeBSD Stand, sponsored
the co-located FreeBSD Developer Summit, and gave the 25 Years of
FreeBSD presentation in the BSD Dev room.
* Sponsored and presented at SANOG33 in Thimphu, Bhutan
* Represented FreeBSD at APRICOT 2019 in Yuseong-gu, Daejeon South
Korea
* Sponsored the USENIX FAST conference in Boston, MA as an Industry
Partner
* Ran our first ever FreeBSD track at SCALE 17x, which included an
all-day Getting Started with FreeBSD workshop. We were thrilled
with the turnout of almost 30 participants and received a lot of
positive feedback. Thanks to Roller Angel who taught the class with
the help of Deb Goodkin and Gordon Tetlow. We also promoted FreeBSD
at the FreeBSD table in the Expo Hall.
* Sponsored, presented, and exhibited at FOSSASIA in Singapore
* Sponsored AsiaBSDCon 2019
* Committed to sponsoring Rootconf, BSDCan, and EuroBSDcon
* Created registration systems for the Aberdeen Hackathon and the
upcoming 2019 Vienna FreeBSD Security Hackathon
* Provided FreeBSD advocacy material
* Provided 3 travel grants to FreeBSD contributors to attend many of
the above events.
We continued producing FreeBSD advocacy material to help people promote
FreeBSD around the world.
Read more about our conference adventures in the conference recaps and
trip reports in our monthly newsletters.
We help educate the world about FreeBSD by publishing the
professionally produced FreeBSD Journal. We're excited to announce that
with the release of the January/February 2019 issue, the FreeBSD
Journal is now a free publication. Find out more and access the latest
issues at www.FreeBSDfoundation.org/journal/.
You can find out more about events we attended and upcoming events at
www.FreeBSDfoundation.org/news-and-events/.
We also engaged with a new website developer to help us improve our
website to make it easier for community members to find information
more easily and to make the site more efficient.
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 www.FreeBSDfoundation.org to find out how we support FreeBSD and
how we can help you!
__________________________________________________________________
FreeBSD Release Engineering Team
Links
FreeBSD 11.3-RELEASE schedule
URL: https://www.freebsd.org/releases/11.3R/schedule.html
FreeBSD development snapshots
URL: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/
Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>
The FreeBSD Release Engineering Team is responsible for setting and
publishing release schedules for official project releases of FreeBSD,
announcing code freezes and maintaining the respective branches, among
other things.
During the first quarter of 2019, the FreeBSD Release Engineering team
published the initial schedule for the upcoming the 11.3-RELEASE.
FreeBSD 11.3-RELEASE will be the fourth release from the stable/11
branch, building on the stability and reliability of 11.2-RELEASE.
FreeBSD 11.3-RELEASE is currently targed for release in early July,
2019.
Additionally throughout the quarter, several development snapshots
builds were released for the head, stable/12, and stable/11 branches.
Much of this work was sponsored by the FreeBSD Foundation.
__________________________________________________________________
Ports Collection
Links
About FreeBSD Ports
URL: https://www.FreeBSD.org/ports/
Contributing to Ports
URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/=
ports-contributing.html
FreeBSD Ports Monitoring
URL: http://portsmon.freebsd.org/index.html
Ports Management Team
URL: https://www.freebsd.org/portmgr/index.html
Contact: Ren=E9 Ladan <portmgr-secretary@FreeBSD.org>
Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>
As always, below is a summary of what happened in the Ports Tree during
the last quarter.
During 2019q1, the number of ports dropped slightly to just over
32,500. At the end of the quarter, we had 2092 open port PRs. The last
quarter saw 8205 commits from 167 committers. So more PRs were closed
and more commits were made than in 2018q4.
During the last quarter, we welcomed Kai Knoblich (kai@) and said
goodbye to Matthew Rezny (rezny@).
On the infrastructure side, two new USES were introduced (azurepy and
sdl) and USES=3Dgecko was removed. The default versions of Lazarus and
LLVM were bumped to 2.0.0 and 8.0 respectively. Some big port
frameworks that were end-of-life were removed: PHP 5.6, Postgresql 9.3,
Qt4, WebKit-Gtk and XPI. Firefox was updated to 66.0.2, Firefox-ESR to
60.6.1, and Chromium was updated to 72.0.3626.121.
During the last quarter, antoine@ ran 30 exp-runs for package updates,
moving from GNU ld to LLVM ld, and switching clang to DWARF4.
__________________________________________________________________
Projects
Projects that span multiple categories, from the kernel and userspace
to the Ports Collection or external projects.
AXP803 PMIC driver update
Contact: Ganbold Tsagaankhuu <ganbold@FreeBSD.org>
The AXP803 is a highly integrated PMIC that targets Li-battery (Li-ion
or Li-polymer) applications. It provides flexible power management
solution for processors such as the Allwinner A64 SoC. This SoC is used
by Pinebook.
The following updates were performed on the AXP803 driver:
* Enabled necessary bits when activating interrupts. This allows
reading some events from the interrupt status registers. These
events are reported to devd via system "PMU" and subsystem
"Battery", "AC" and "USB" such as plugged/unplugged, battery
absent, charged and charging.
* Added sensors support for AXP803/AXP813. Sensor values such as
battery charging, charge state, voltage, charging current,
discharging current, battery capacity can be obtained via sysctl.
* Added sysctl for setting battery charging current. The charging
current can be set using steps from 0 to 13. These steps correspond
to 200mA to 2800mA, with a granularity of 200mA/step.
__________________________________________________________________
Broadcom ARM64 SoC support
Contact: Michal Stanek <mst@semihalf.com>
Contact: Marcin Wojtas <mw@semihalf.com>
The Semihalf team continued working on FreeBSD support for the Broadcom
BCM5871X SoC series
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.
Completed since the last update:
* iProc PCIe root complex (internal and external buses)
* OTP (One Time Programmable memory) driver
In progress:
* BNXT Ethernet support
* Crypto engine acceleration for IPsec offloading.
Todo:
* Upstreaming of work. This work is expected to be submitted/merged
to HEAD in the second half of 2019.
This project was sponsored by Juniper Networks, Inc.
__________________________________________________________________
C Runtime changes
Contact: Konstantin Belousov <kib@freebsd.org>
Several changes where made to the C runtime which generally improves
the environment provided to an application.
Fix for libraries with initial exec TLS mode
Some libraries, most prominent of which is NVidia-provided and thus
binary-only libGL.so.1, use so called initial exec mode for TLS
variables access. This is the fastest mode of TLS access, but its
drawback is that it only reliably work when the main binary is linked
against the library, i.e. dlopen-ing the library to load it at runtime
is not guaranteed to work.
This mode works by placing the TLS variables for objects in one area
allocated during the executable initialization, which somewhat explains
the name of the mode. An obvious consequence is that if such library is
loaded later, there is no space in the TLS area for an application to
put its TLS variables.
The FreeBSD dynamic linker is aware of misbehaviour of the app
builders, and provides some amount of slack in the TLS area to give
space for such libraries. But it appeared that the initial content of
the TLS segment from libraries was not distributed among the threads'
TLS areas, still breaking libraries which use initial exec mode for
TLS.
Another issue that somewhat mitigates mis-use of the mode is the
DF_STATIC_TLS flag in the dynamic section. This flag allows the linker
to check for the space earlier and avoid loading dependencies if there
is no total required space. This linker flag was implemented by the BFD
ld linker, but not by the LLVM lld linker.
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.
Simultaneously, LLD was improved to mark libraries using initial exec
TLS mode with the appropriate flag.
These measures should make FreeBSD more resilent to improperly linked
libraries. The most interesting fix is to users of the nvidia libgl
library, because it cannot be fixed by relinking.
Use rtld malloc in libthr
The FreeBSD implementation of mutexes in libthr allocates some memory
to keep the mutex data needed for mutex initialization. In contrast,
the malloc implementation used by FreeBSD, jemalloc(3), requires
working pthread mutexes for operation.
This creates a chicken-and-egg problem during executable startup, and
requires jemalloc to provide fragile hacks to make it possible to
initialize mutexes. This has been a constant source of mismatches on
imports of new versions of jemalloc.
The FreeBSD rtld implementation already contained a very light-weight
malloc implementation, suitable for limited use in pre-C-runtime
environments. This seemed to be the ideal fit for an allocator for the
pthread private mutexes memory. By using this allocator, a method to
address the cyclic dependencies between jemalloc and libthr could
finally be implemented.
The entry points in the rtld malloc.c were renamed to avoid a clash
with the libc exported symbols, and now the file is linked statically
into libthr, providing an allocator for private mutexes and pthread key
storage. The later was already switched to direct use of mmap(2) for
similar reasons. Now less memory is wasted when key storage requires
less than a page.
Destructors order bug
Alexander Kabaev (kan@) noted that C++ destructors for the static
objects from the linked shared libraries are executed before C++
destructors of the static objects from the main binary. This was
verified both for clang++ and g++, but amusingly not for
__attribute__(((destructor))).
The bug was introduced when init functions and init arrays for main
binary startup are called from the rtld instead of csu (C startup code
linked to the binary, typically from crt1.o). The cause is due to the
somewhat complicated way of how destructors are called both by
fini/fini arrays and rtld-registered atexit(3) handler.
Solution is to register rtld atexit(3) handler before main binary init
functions are called, using new internal ABI __libc_atexit() function.
It is amusing that the bug was not noticed for so many years.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Capsicum
Links
Capsicum Wiki Page
URL: https://wiki.FreeBSD.org/Capsicum
Contact: Enji Cooper <ngie@freebsd.org>
Contact: Mark Johnston <markj@FreeBSD.org>
Contact: Ed Maste <emaste@FreeBSD.org>
Contact: Mariusz Zaborski <oshogbo@FreeBSD.org>
Contact: Bora =D6zarslan <borako.ozarslan@gmail.com>
Three themes for Capsicum work were:
* Importing Google's Capsicum test suite into FreeBSD
* Porting and sandboxing openrsync for FreeBSD
* Applying capsicum to additional base system utilities
The Googletest-based Capsicum test cases are now integrated into
FreeBSD. After some discussion with David Drysdale - the main
maintainer and developer for the Capsicum port on Linux - we decided
that from now the FreeBSD will be upstream for Capsicum test cases.
The next major step was sandboxing openrsync. In the course of that
work we extended our fileargs service with two new functionalities. We
modified the fileargs service to allow limiting the operations which
can be performed, and can now delegate lstat to the Casper service.
Furthermore, openrsync highly depends on the fts API. We spend some
time in optimizing fts and making it sandbox friendly by introducing
fts_openat function and removing the need to change the working
directory to traverse the paths. The changes to the fts API are now in
the tests phase.
Moreover, we improved bootstrapping for non-FreeBSD machines. Thanks to
this work we can now build tools needed to bootstrap FreeBSD which use
Casper services. In the base system strings is now sandboxed as a
result.
We also sandboxed rtsol, rtsold, and savecore.
We host biweekly Capsicum calls. The notes from the meetings are
published in FreeBSD's Capsium meeting repository on GitHub. If you
would like to join the call do not hesitate to send us an email.
__________________________________________________________________
CFT - Package Base
Links
Package Base CFT - FAQ
URL: https://trueos.github.io/pkgbase-docs/
Contact: Kris Moore <kmoore@FreeBSD.org>
The TrueOS project has been working on a Package Base implementation,
and is pleased to issue its first CFT to the FreeBSD community.
The TrueOS packaging work has been in development for close to 6
months, and differs from the original FreeBSD package base effort, in
that it is an "out of tree" implementation. It allows any version of
FreeBSD to be packaged, and only requires a patch to poudriere, as well
as some minor ports enhancements, the first which is currently in
review. For more information on the current status, please refer to the
FAQ page.
Additionally there will be a working-group at BSDCan 2019, and we
encourage porters to attend and join the discussion.
This project was sponsored by iXsystems Inc.
__________________________________________________________________
ENA FreeBSD Driver Update
Links
ENA README
URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R=
EADME
Contact: Michal Krawczyk <mk@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.
ENAv2 has been under development for FreeBSD, similar to Linux and
DPDK. Since the last update internal review and improvements of the
patches were done, followed by validation on various AWS instances.
To do:
* Upstream of the ENAv2 patches
Recently, AWS released the A1 instances which are arm64 instances. The
FreeBSD kernel was fixed, so the ENA can be used on those instances
with no issues. There were changes required in resource activation in
the ENA driver r345371 and the addition of a missing bus release method
to the nexus module for aarch64 r345373. With these changes, the ENA
driver can run on A1 instances without any known issues.
This project was sponsored by Amazon.com Inc.
__________________________________________________________________
FreeBSD boot security improvements
Links
Veriexec manifest verification in kernel
URL: https://svnweb.freebsd.org/changeset/base/345830
TPM as entropy source
URL: https://svnweb.freebsd.org/changeset/base/345438
UEFI support in libsecureboot
URL: https://svnweb.freebsd.org/changeset/base/344840
Contact: Michal Stanek <mst@semihalf.com>
Contact: Marcin Wojtas <mw@semihalf.com>
Contact: Kornel Duleba <mindal@semihalf.com>
FreeBSD gained TPM 2.0 (Trusted Platform Module) support at the end of
2018. A kernel configuration option, TPM_HARVEST, was also added to use
the TPM RNG as system entropy source. When used this way, the TPM can
be harvested every ten seconds for entropy which is mixed into the OS
entropy pool. The kernel option is currently disabled by default in
amd64 GENERIC kernel configuration.
UEFI Secure Boot support, developed by Semihalf, has been merged with
sjg's Veriexec support, resulting in a unified library named
libsecureboot. 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 blacklisted
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.
To do:
* Backport to stable branches.
Special thanks to sjg and Juniper for fruitful cooperation around
Veriexec and the libsecureboot development.
This project was sponsored by Stormshield.
__________________________________________________________________
FUSE
Contact: Alan Somers <asomers@FreeBSD.org>
FUSE (File system in USErspace) allows a userspace program to implement
a file system. It is widely used to support out-of-tree file systems
like NTFS, as well as for exotic pseudo file systems like sshfs.
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.
The FreeBSD Foundation has agreed to fund a project to improve the
state of the FreeBSD FUSE driver. So far I've written a test suite for
the fusefs(5) module, fixed 1 previously reported bug, discovered and
fixed 6 new bugs, fixed all of fusefs's Coverity CIDs, made some minor
performance enhancements and done some general cleanup. During the next
quarter I plan to continue fixing bugs, and I'll also raise the
driver's API level as high as I can before the quarter runs out. We're
currently at 7.8; the highest defined level is 7.28.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Kernel ZLIB Update
Links
Review D19706
URL: https://reviews.freebsd.org/D19706
Contact: Yoshihiro Ota <ota@j.email.ne.jp>
The FreeBSD system still uses an ancient (over 20 year-old) version of
zlib (version 1.0.4). The FreeBSD kernel zlib implementation has
special enhancements only used by netgraph. There is a separate version
of code derived from unzip 5.12 used to inflate gzip files in the
kernel which could be replaced with a more modern zlib. More detailed
information is written in sys/modules/zlib/README in the review.
In order to use the latest zlib, version 1.2.11, work has been done to
revisit all existing zlib uses in the system. Most of the code works
with the newer version of zlib as is. The unzip code will need some
conversion work to use the newer zlib. A few callers will be made
simplier by using some newer APIs available in the updated zlib. There
are some zombie programs that have been broken and I would like to
delete.
This will clean up zombie programs and duplicated zlib code. This will
also make future zlib version updates easier.
These changes touch some very sensitive areas of the system, such as
kernel loading, or are architecture specific like armv6/armv7, and also
touch some legacy code like kgzip+kgzldr on i386. Testers and active
users of these legacy zlib code are welcomed.
* armv elf_trampoline Arm up to v5 can boot from gzipped kernel. This
code is modified to use newer API for simplicity. Please verify
gzipped kernel still boots with new code (Current code has fall
back to legacy zlib in case of failure). Please also elaborate how
to link such kernel, too. I'm still trying to figure that out.
* netgraph compression/decompression Please help testing and/or teach
how to test. Netgraph compiles in the FreeBSD zlib version inside.
* gzipped a.out Does anyone use gzipped a.out executables, still? If
so, does someone have an easy and safe program to run? Is a.out
format i386 only?
* zfs boot Can we boot from gzipped file system today?
* CTF Checking how I can test.
__________________________________________________________________
LLVM's lld as the FreeBSD system linker
Links
LLD on the FreeBSD Wiki
URL: https://wiki.freebsd.org/LLD
lld exp-run =20
URL: https://bugs.freebsd.org/214864
Contact: Ed Maste <emaste@freebsd.org>
In FreeBSD-HEAD and 12.0 the default FreeBSD system linker (i.e.,
/usr/bin/ld) is LLVM's lld, on amd64, arm64, and armv7. For i386 in
12.0 lld is used as the bootstrap linker (i.e., to build the kernel and
base system) but it is not enabled as the system linker because of
multiple issues building FreeBSD ports with it enabled.
The primary issue affecting i386 with lld is that many ports build
position-dependent code (i.e., non-PIC) for use in shared libraries.
This either comes from omitting the -fPIC compiler flag, or using
hand-written position-dependent assembly. Compared with other CPU
architectures i386 position-independent code is rather inefficient,
which may be responsible for port authors making an explicit decision
to avoid PIC.
By default lld does not allow position-dependent code in shared objects
(in particular, it does not permit relocations against read-only
segments - typically containing the`.text` section).
Over the last quarter many commits were made to the ports tree to fix
the build when the system linker is lld - either building PIC code, or
adding the -znotext linker flag to permit relocations against read-only
segments, or just switching the port to link with GNU ld if it is
incompatible with lld in some other way.
At this point there are only a few dozen open bug reports for issues
linking ports with lld as the system linker, and I expect FreeBSD 12.1
to use lld as the system linker on i386 as well.
Tasks:
* Fix freepascal/Lazarus ports with lld
* Triage and address remaining port failures
* Holistic review of lld workarounds in the ports tree, to identify
changes that are no longer needed, should be addressed in lld, or
should be sent upstream
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
mlx5 Drivers Update
Links
Mellanox OFED for FreeBSD Documentation
URL: http://www.mellanox.com/page/products_dyn?product_family=3D193&mta=
g=3Dfreebsd_driver
Contact: Slava Shwartsman, Hans Petter Selasky, Konstantin Belousov <fre=
ebsd-drivers@mellanox.com>
The mlx5 driver provides support for PCI Express adapters based on
ConnectX-4(LX), ConnectX-5(EX) and ConnectX-6(DX). The mlx5en driver
provides support for Ethernet and the mlx5ib driver provides support
for InfiniBand and RDMA over Converged Ethernet, RoCE.
Following updates done in mlx5 drivers:
* Added support for ConnectX-6 and ConnectX-6dx devices, which
support of up to 200Gb/s interface speeds!
* Added TLS hardware offload support for ConnectX-6dx devices. TLS Tx
crypto offload is a new feature for network devices. It enables the
kernel TLS socket to skip encryption and authentication operations
on the transmit side of the data path, delegating those to the NIC.
In turn, the network adapter encrypts packets that belong to an
offloaded TLS socket on the fly. The Mellanox network adapter does
not modify any packet headers. It expects to receive fully framed
TCP packets with TLS records as payload. The NIC replaces plaintext
with ciphertext and fills the authentication tag. The adapter does
not hold any state beyond the context needed to encrypt the next
expected packet, i.e. expected TCP sequence number and crypto
state.
* Add support for Dynamic Receive Queue Interrupt Moderation. Dynamic
Interrupt Moderation (DIM) refers to any action made by hardware
and/or software on run time to control interrupt rate on the
system. The moderation action itself should not interfere with the
system's operation and should not require any human interaction. In
networking, dynamic interrupt moderation is used for controlling
the rate of interrupts generated by the hardware for multiple
traffic scenarios.
* Enhanced support for self-healing mechanism: In a rare occasion
when Mellanox network adapters fail, due to a firmware bug for
example, the driver will sense the catastrophic error. As a result
of this failure detection, the device driver can trigger a firmware
reset for the device so it can recover - without the need to reboot
the entire host.
* Added support for in-driver firmware updating using mlx5tool.
This project was sponsored by Mellanox Technologies.
__________________________________________________________________
PCI Express Resets
Contact: Konstantin Belousov <konstantinb@mellanox.com>
Sometimes the need to reset a device attached to the system presents
itself. Preferrably this device reset can be accomplished without
causing the whole machine to reboot. It is easy to do with USB devices
if the physical access is available -- you can just re-plug the device.
For in-chassis devices, built-in, or on add-on cards, it is not
possible to reset the device with physical action, unless the device is
hot-plugged. Nonetheless, for typical modern PCIe devices, and most
built-in PCI-emulation devices, the reset can be initiated using
software actions.
If device is a real plugged-in PCIe device, then reset can be initiated
by disabling and then re-training PCIe-link by the upstream port
controls. For most PCI devices, which support the PCI power management
specification, the proven way to accomplish the reset is to put the
device into state D3 (off) and then return to the previous power state.
FreeBSD was missing a way to conveniently request user- or
driver-initiated reset of devices. While it was possible to manually
fiddle with registers using pciconf, this is impractical for users, and
requires a lot of boilerplate code from drivers.
A new BUS_RESET_CHILD() method was added to the newbus bus interface,
and implementations added for PCIe bridges and PCI devices. The
libdevctl(3) library call and devctl(8) command provide convenient
userspace accessors for applications and administrators.
During the reset, the device driver must stop its operations with the
device. One way to achieve this is to detach drivers before reset, and
re-attach after the device afterwards. This is mostly fine for network
interfaces, but other devices require more coordination to handle
properly. For example, an NVMe disk device being detached it means that
all mounted volumes abruptly disapper from VFS view. Due to this, the
BUS_RESET_CHILD() method allows the caller to select either
detach/re-attach or suspend/resume driver actions around the reset.
Mellanox uses the infrastructure to perform reset of the mlx(5) card
after firmware reset without server reboot. It is believed that 'devctl
reset' will be more widely useful.
This project was sponsored by Mellanox Technologies.
__________________________________________________________________
Security-Related changes
Contact: Konstantin Belousov <kib@freebsd.org>
ASLR
The ASLR (Address Space Layout Randomization) patch from review D5603
was committed into svn. 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.
KPTI per-process control
The KPTI (Kernel Page Table Isolation) implementation was structured so
that most selections of page isolation mode were local to the current
address space. In other words, the global control variable pti was
almost unused in the code paths, instead the user/kernel %cr3 values
were directly loaded into registers or compared to see if the user page
table was trimmed. Some missed bits of code were provided by Isilon,
and then bugs were fixed and last places of direct use of pti were
removed.
Now when the system starts in the pti-enabled mode, proccontrol(1) can
be used by root to selectively disable KPTI mode for children of a
process. The motivation is that if you trust the program that you run,
you can get the speed of non-pti syscalls back, but still run your
normal user session in PTI mode. E.g., firefox would be properly
isolated.
Feature-control bits
Every FreeBSD executable now contains a bit mask intended for
enabling/disabling security-related features which makes sense for the
binary. This mask is part of the executable segments loaded on image
activation, and thus is part of any reasonable way to authenticate the
binary content.
For instance, the ASLR compatibility is de-facto the property of the
image and not of the process executing the image. The first (zero) bit
in the mask controls ASLR opt-out. Other OSes (e.g. Solaris) used an
OS-specific dynamic flag, which has the same runtime properties but
leaves less bits to consume in the feature-control mask.
The feature-control mask is read both by kernel and by rtld during
image activation. It is expected that more features will be added to
FreeBSD and the mask can be used for enabling/disabling those
features..
It is expected that a tool to manipulate the mask will be provided
shortly, see review D19290.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
Architectures
Updating platform-specific features and bringing in support for new
hardware platforms.
FreeBSD/RISC-V Update
Contact: Ruslan Bukin <br@FreeBSD.org>
Contact: Mitchell Horne <mhorne@FreeBSD.org>
Contact: Mark Johnston <markj@FreeBSD.org>
Work has continued on RISC-V port in the past quarter.
Support for transparent superpage promotion was added to the RISC-V
port, meaning that applications will now automatically use large page
mappings when possible. Per-CPU pmap activation tracking was added,
reducing the overhead of various pmap operations. This noticeably
improves the responsiveness of FreeBSD when running in a multi-CPU
virtual machine.
A RISC-V implementation of minidumps was completed. Support for
debugging RISC-V kernel dumps will land in devel/gdb after the next GDB
release.
It is now possible to compile the in-tree LLVM's RISC-V target by
setting WITH_LLVM_TARGET_RISCV=3DYES in /etc/src.conf. The use of LLVM to
compile the RISC-V port is currently experimental and further
investigation is ongoing.
Work is ongoing to bring up FreeBSD on SiFive's HiFive Unleashed
development board now that one has been obtained by a FreeBSD
developer. We also expect to work on support for a new version of the
SBI specification.
This project was sponsored by The FreeBSD Foundation, DARPA, AFRL.
__________________________________________________________________
Ports
Changes affecting the Ports Collection, whether sweeping changes that
touch most of the tree, or individual ports themselves.
FreeBSD GNOME status report
Links
GNOME FreeBSD =20
URL: https://freebsd.org/gnome/
GNOME development Repo
URL: https://github.com/freebsd/freebsd-ports-gnome
Contact: Koop Mast <kwm@FreeBSD.org>
Contact: Eric Turgeon <ericbsd@FreeBSD.org>
Ports activity in this quarter were:
* The x11-toolkits/gtk30 port updated to 3.24.5 and later to 3.24.7.
* The www/webkit2-gtk3 port was updated to 2.24.0.
* And the old insecure webkit-gtk2 and webkit-gtk3 where finally
removed.
Work in progress, the branches are available in the GNOME development
repo, see the link above.
* Eric Turgeon is working on MATE 1.22 in the mate-1.22 branch. And
is almost complete.
* Charlie Li (IRC: vishwin) is working on a long overdue update of
the cinnamon desktop. This update is almost complete. The only real
blocker is that the screensaver can't be unlocked after it
activates. The work is in the cinnamon branch.
* Koop Mast works on GNOME 3.32. The desktop is usable apart from gdm
which is currently non-functional. Due to lack of free time the
work is going slowly. This work is available in the gnome-3.32
branch.
People who are willing to contribute can find us on #freebsd-gnome on
freenode.
__________________________________________________________________
FreeBSD KDE status report
Links
KDE FreeBSD
URL: https://freebsd.kde.org/
Contact: Adriaan de Groot <adridg@FreeBSD.org>
Contact: Tobias C. Berner <tcberner@FreeBSD.org>
The two biggest accomplishements this quarter were:
* Qt4 and all its consumers have been removed from the ports tree.
* www/qt5-webengine has been updated from the ancient 5.9.4 to 5.12.x
by kai@
Further we have kept the KDE Frameworks, Plasma and Applications ports
up to date with upstreams releases, which thanks to upstreams'
FreeBSD-CI uses less and less patches.
All the kde@ maintained ports (including cmake) have been kept up to
date with their releases.
The plans for the next quarter are in no particular order
* Cleanup PyQt ports and pyqt.mk
* Improve qt.mk components
* Update sddm to 0.18.x
* Implement user management functionality in system settings (write
non-logind backend)
People who are willing to contribute can find us on #kde-freebsd on
freenode, and the kde@FreeBSD.org mailing list. Further we accept
pull-requests and contributions on
github.com/freebsd/freebsd-ports-kde.
__________________________________________________________________
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.
FreeBSD Wiki Apple Intel Mac mini update
Links
FreeBSD Wiki
URL: https://wiki.freebsd.org/IntelMacMini
Contact: Trevor Roydhouse <fbsdwiki@gmx.net>
The FreeBSD Wiki page for the Apple Intel Mac minis has been
comprehensively updated over the last quarter to drag it from 2009 into
2019.
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.
If anyone is interested, help is needed to provide more specific
information for the macmini 1,1 and 6,1 through 8,1 models and to test
patches for the asmc(4) driver for temperature sensor feedback and for
setting fan speed. If you would like to help and have access to these
Mac minis, please contact me.
Future tasks:
* Create and test more patches for asmc(4) to cover all Intel Mac
minis
* Provide more information for 2006, 2012, 2014 and 2018 Mac minis
* Instructions for dual boot (macOS/FreeBSD) installations
__________________________________________________________________
Fuzzing FreeBSD with syzkaller
Links
syzkaller
URL: https://github.com/google/syzkaller
Contact: Mark Johnston <markj@FreeBSD.org>
Contact: Andrew Turner <andrew@FreeBSD.org>
Contact: Michael Tuexen <tuexen@FreeBSD.org>
Contact: Ed Maste <emaste@FreeBSD.org>
Syzkaller is a coverage-guided system call fuzzer. It was originally
developed for Linux. It programmatically creates programs consisting of
sequences of random system calls and executes them in a VM (virtual
machine). Using feedback from a kernel code coverage facility called
kcov, syskaller mutates the generated test programs in an attempt to
expand the executed coverage of code paths within the kernel. Sometimes
exercising a seldom or infrequently used code path will crash the
kernel. When syzkaller manages to crash the running kernel in the VM,
it attempts to generate a minimal test case which reproduces the crash,
simplifying debugging. Syzkaller is very effective at finding kernel
bugs and has uncovered hundreds of issues in Linux. Over the past
couple of years, syzkaller's author, Dmitry Vyukov, has added support
for other operating systems, including FreeBSD.
Recently, a number of FreeBSD developers have been using syzkaller to
find and fix bugs in the FreeBSD kernel. If interested, one can search
the commit logs for "syzkaller" to find examples. Syzkaller can be run
on a FreeBSD or Linux host to fuzz FreeBSD running in QEMU instances.
It can also fuzz FreeBSD instances running on GCE (Google Compute
Engine). Additionally, Google maintains a dedicated cluster of GCE
hosts to continuously fuzz the latest builds of several different OS
kernels. A FreeBSD target was recently added. Subscribe to the
syzkaller-freebsd-bugs Google Group to receive notifications for newly
discovered bugs.
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. Similarly, many ioctl(2)
definitions are missing.
Some in-progress work aims to add support for bhyve as a VM backend for
syzkaller, making it easier to fuzz FreeBSD VMs hosted on FreeBSD.
Currently that can be done using QEMU, but QEMU on FreeBSD lacks
support for hardware acceleration. See the PR for the implementation.
Finally, a number of bugs identified by syzkaller have yet to be fixed.
If you are interested in helping out with any of the above, please mail
the contacts listed above.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
sysctlmibinfo API 1.0
Links
gitlab.com/alfix/sysctlmibinfo
URL: https://gitlab.com/alfix/sysctlmibinfo
Contact: Alfonso Sabato Siciliano <alfonso.siciliano@email.com>
Port: devel/libsysctlmibinfo
The sysctl() system call can get or set the value of a 'property' of
the system. A 'property' has others info (description, type, label,
etc.), they are necessary to build an utility like /sbin/sysctl,
example:
% sysctl -d kern.ostype
kern.ostype: Operating system type
% sysctl -t kern.ostype
kern.ostype: string
Primarily sysctlmibinfo wraps the undocumented kernel interface and
provides an easy C API: sysctlmif_name(), sysctlmif_description(),
sysctlmif_info(), sysctlmif_label(), sysctlmif_nextnode() and
sysctlmif_nextleaf(), to retrieve the info of a 'property'.
Moreover sysctlmibinfo provides a high level API: defines a struct
sysctlmif_object and has some function: sysctlmif_filterlist(),
sysctlmif_grouplist() and sysctlmif_tree(), to build lists and trees of
objects.
You can use this library to quickly build a custom sysctl utility. For
example, the core of deskutils/sysctlview (a graphical explorer for the
sysctl MIB Tree) is just a call to sysctlmif_tree() and a visit to the
resulting tree to show its sysctlmif_object nodes.
Note, actually a 'property' is an OID of the sysctl MIB, it is
implemented by a struct sysctl_oid defined in sys/sysctl.h.
__________________________________________________________________
sysctlview 1.0
Links
gitlab.com/alfix/sysctlview
URL: https://www.gitlab.com/alfix/sysctlview
Contact: Alfonso Sabato Siciliano <alfonso.siciliano@email.com>
Port: deskutils/sysctlview
The FreeBSD's kernel maintains a Management Information Base where the
objects are properties to tuning the system using the sysctl() syscall
and the /sbin/sysctl utility. The sysctlview utility is a "graphical
sysctl MIB explorer", it depends on gtkmm (to build a GUI) and
sysctlmibinfo (to retrieve the info from the kernel).
The version 1.0 provides two "TreeView":
* "Main" to show 'name', 'description', 'type', 'format' and 'value'
* "Flags" to show 'name' and a column for each 'flag' defined in
sys/sysctl.h
The rows are "clickable" to display others info (e.g., 'label').
Currently sysctlview can show numeric and string values, the support
for some opaque value will be added in the future.
__________________________________________________________________
University of Waterloo Co-operative Education Students
Contact: Ed Maste <emaste@freebsd.org>
For the January-April 2019 term the FreeBSD Foundation has again
brought on two co-operative education (co-op) students from the
University of Waterloo.
Gerald Aryeetey is a 2nd year Computer Engineering student. Gerald
started looking at a FreeBSD tool chain issue - our static library
archiver (ar) did not read or write archives in the 64-bit format.
Gerald submitted a libarchive change to support 64-bit archives
followed by change to FreeBSD's ar to add 64-bit support.
Gerald later looked at a number of freebsd-update issues in FreeBSD's
bugzilla database, and submitted many fixes. Around a dozen have been
committed to FreeBSD, and more are in review.
Gerald also worked on the FreeBSD Foundation's hardware continuous
integration effort. The prototype installation is building FreeBSD on a
commit-by-commit basis and testing on a BeagleBone Black and a Pine64
LTS. The prototype will be converted to a permanent, public
installation in the near future, after which additional test devices
will be added.
For his final project Gerald intends to write a device driver for the
Microchip LAN743x PCIe NIC.
Bora =D6zarslan is a 3rd year student in Computing and Financial
Management. Bora's initial focus was also on tool chain issues in
FreeBSD, starting with improvements or bug fixes in FreeBSD's readelf
(from the ELF Tool Chain project).
Bora developed a tool to modify feature control bits in ELF binaries -
for example, allowing binaries incompatible with ASLR to request to
opt-out. As part of his readelf work Bora also added support to report
the status of the feature control bits.
Bora continued investigating security topics, looking at applying
Capsicum sandboxing to Kristaps' BSD licensed rsync implementation,
openrsync. This work required first implementing fileargs_lstat support
in cap_fileargs (which as now been committed) as well as changes to the
fts directory hierarchy routines (which have not yet been committed to
FreeBSD).
For the rest of the work term Bora will investigate and test unmodified
Linux Docker containers on FreeBSD, to evaluate the state of
Linuxulator support.
This project was sponsored by The FreeBSD Foundation.
__________________________________________________________________
--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQGmBAEBCgCQFiEEbvjBe1hu6u1NeinjJCKD+Vwk/7oFAlz2bCxfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDZF
RjhDMTdCNTg2RUVBRUQ0RDdBMjlFMzI0MjI4M0Y5NUMyNEZGQkESHHRyYXN6QGZy
ZWVic2Qub3JnAAoJECQig/lcJP+6vQEH/1PyJpCjUnDgEnJbQH1pbfE35cGSVznN
ru6aT8XbSYR/qaAUs2aZ/hzaXTm7KqEfnid/UHr25gw4kQq1BBEqJcm7vzrTJmik
w/M1ZhH4CbvWmYdz/avH4AJo91ayjPfl9tniAVAoMHVhcO/y2K/6pv4M/7LsY1bp
dG7vU9VEe+QOrA/5NURf72E5RwYAn/E7jllqc8FUHuy/54iSMkbYw5bf5lYD2nQP
v1VTWjdwp8kIbA23ci4vHyHE1HEggY7Ukrgnh1GprEwIVtKqhxwi5fcSFK+s0v13
FvI54ZSrQLAtQAxFVzXrPrEb4loHcBHtGU37WdbW4nCzC3I7ynZWVI4=
=jsrm
-----END PGP SIGNATURE-----
--AhhlLboLdkugWU4S--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190604130340.GA2359>