<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
Status Report//EN"
"http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
<!-- $FreeBSD$ -->
<!-- This file was generated with https://github.com/trasz/md2docbook -->
<!--
Variables to replace:
%%START%% - report month start
%%STOP%% - report month end
%%YEAR%% - report year
%%NUM%% - report issue (first, second, third, fourth)
%%STARTNEXT%% - report month start
%%STOPNEXT%% - report month end
%%YEARNEXT%% - next report due year (if different than %%YEAR%%)
%%DUENEXT%% - next report due date (i.e., June 6)
-->
<report>
<date>
<month>January-March</month>
<year>2019</year>
</date>
<section>
<title>Introduction</title>
<p>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.</p>
</section>
<category>
<name>team</name>
<description>&os; Team Reports</description>
<p>Entries from the various official and semi-official teams,
as found in the <a href="&enbase;/administration.html">Administration
Page</a>.</p>
</category>
<category>
<name>proj</name>
<description>Projects</description>
<p>Projects that span multiple categories, from the kernel and userspace
to the Ports Collection or external projects.</p>
</category>
<category>
<name>arch</name>
<description>Architectures</description>
<p>Updating platform-specific features and bringing in support
for new hardware platforms.</p>.
</category>
<category>
<name>ports</name>
<description>Ports</description>
<p>Changes affecting the Ports Collection, whether sweeping
changes that touch most of the tree, or individual ports
themselves.</p>
</category>
<category>
<name>third</name>
<description>Third-Party Projects</description>
<p>Many projects build upon &os; or incorporate components of
&os; into their project. As these projects may be of interest
to the broader &os; community, we sometimes include brief
updates submitted by these projects in our quarterly report.
The &os; project makes no representation as to the accuracy or
veracity of any claims in these submissions.</p>
</category>
<project cat='team'>
<title>FreeBSD Release Engineering Team</title>
<contact>
<person>
<name>FreeBSD Release Engineering Team</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://www.freebsd.org/releases/11.3R/schedule.html">FreeBSD 11.3-RELEASE schedule</url>
<url href="https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/">FreeBSD development snapshots</url>
</links>
<body>
<p>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.</p>
<p>During the first quarter of 2019, the FreeBSD Release
Engineering team
published the initial schedule for the upcoming the
11.3-RELEASE.</p>
<p>FreeBSD 11.3-RELEASE will be the fourth release from the
<tt>stable/11</tt>
branch, building on the stability and reliability of
11.2-RELEASE.
FreeBSD 11.3-RELEASE is currently targed for release in
early July, 2019.</p>
<p>Additionally throughout the quarter, several development
snapshots builds
were released for the <tt>head</tt>, <tt>stable/12</tt>,
and <tt>stable/11</tt> branches.</p>
<p>Much of this work was sponsored by the FreeBSD Foundation.</p>
</body>
</project>
<project cat='team'>
<title>Ports Collection</title>
<contact>
<person>
<name>René Ladan</name>
<email>portmgr-secretary@FreeBSD.org</email>
</person>
<person>
<name>FreeBSD Ports Management Team</name>
<email>portmgr@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://www.FreeBSD.org/ports/">About FreeBSD Ports</url>
<url href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">Contributing to Ports</url>
<url href="http://portsmon.freebsd.org/index.html">FreeBSD Ports Monitoring</url>
<url href="https://www.freebsd.org/portmgr/index.html">Ports Management Team">Ports Management Team</url>
</links>
<body>
<p>As always, below is a summary of what happened in the
Ports Tree during the
last quarter.</p>
<p>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.</p>
<p>During the last quarter, we welcomed Kai Knoblich (kai@)
and said goodbye to
Matthew Rezny (rezny@).</p>
<p>On the infrastructure side, two new USES were introduced
(azurepy and sdl) and
USES=gecko 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.</p>
<p>During the last quarter, antoine@ ran 30 exp-runs for
package updates, moving
from GNU ld to LLVM ld, and switching clang to DWARF4.</p>
</body>
</project>
<project cat='team'>
<title>FreeBSD Core Team</title>
<contact>
<person>
<name>FreeBSD Core Team</name>
<email>core@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The FreeBSD Core Team is the governing body of FreeBSD.</p>
<p>Core initiated a <tt>Release Engineering Charter
Modernization</tt> working
group. The purpose of the working group is to present (to
Core) a
modernized version of the <tt>Release Engineering
Charter</tt> and a first
version of a new <tt>Release Engineering Team Operations
Plan</tt>. The
group hopes to complete its goals and dissolve by
2019-06-30.</p>
<p>The Core Team invites all members of the FreeBSD community
to
complete the <tt>2019 FreeBSD Community Survey</tt>.</p>
<p>https://www.research.net/r/freebsd2019</p>
<p>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)</p>
<p>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.</p>
<p>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.</p>
<ul>
<li>Alfred Perlstein (alfred@)</li>
<li>Eric Badger (badger@)</li>
<li>Daniel Eischen (deischen@)</li>
<li>Ermal Luçi (eri@)</li>
<li>Tony Finch (fanf@)</li>
<li>Justin T. Gibbs (gibbs@)</li>
<li>Imre Vadász (ivadasz@)</li>
<li>Julio Merino (jmmv@)</li>
<li>John W. De Boskey (jwd@)</li>
<li>Kai Wang (kaiw@)</li>
<li>Luigi Rizzo (luigi@)</li>
<li>Neel Natu (neel@)</li>
<li>Craig Rodrigues (rodrigc@)</li>
<li>Stanislav Sedov (stas@)</li>
<li>Thomas Quinot (thomas@)</li>
<li>Andrew Thompson (thompsa@)</li>
<li>Pyun YongHyeon (yongari@)</li>
<li>Zbigniew Bodek (zbb@)</li>
</ul>
<p></p>
</body>
</project>
<project cat='team'>
<title>FreeBSD Foundation</title>
<contact>
<person>
<name>Deb Goodkin</name>
<email>deb@FreeBSDFoundation.org</email>
</person>
</contact>
<body>
<p>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.</p>
<p>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.</p>
<p>Here are some highlights of what we did to help FreeBSD
last quarter:</p>
<p>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.</p>
<p>Partnerships and Commercial User Support</p>
<p>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.</p>
<p>Fundraising Efforts</p>
<p>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
<a
href="https://www.FreeBSDfoundation.org/donate/">donation</a>
to help us continue and increase our support for FreeBSD
at:
<a
href="https://www.FreeBSDfoundation.org/donate/">www.FreeBSDfoundation.org/donate/</a>.</p>
<p>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!</p>
<p>OS Improvements</p>
<p>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.</p>
<p>Over the quarter there were 241 commits from nine
Foundation-sponsored staff
members and grant recipients.</p>
<p>We kicked off or continued the following projects last
quarter:</p>
<ul>
<li>FUSE file system kernel support (update and bug fixes)</li>
<li>Linuxulator testing and diagnostics improvements</li>
<li>SDIO and WiFi infrastructure improvements</li>
<li>x86-64 scalability and performance improvements</li>
<li>OpenZFS Online RAID-Z Expansion</li>
</ul>
<p>
Having software developers on staff has allowed us to jump
in and
work directly on projects to improve FreeBSD like:</p>
<ul>
<li>amd64 and i386 pmap improvements and bugfixes</li>
<li>address userland threading library issues</li>
<li>improve i386 support to keep the platform viable</li>
<li>improve FreeBSD on RISC-V</li>
<li>application of the Capsicum sandboxing framework</li>
<li>build system improvements and bug fixes</li>
<li>respond to reports of security issues</li>
<li>implement vulnerability mitigations</li>
<li>tool chain updates and improvements</li>
<li>adding kernel code coverage support for the
<a
href="https://github.com/google/syzkaller">Syzkaller</a>
coverage-guided system call
fuzzer</li>
<li>improved Syzkaller support for FreeBSD</li>
<li>improve the usability of <tt>freebsd-update</tt></li>
<li>improve network stack stability and address race
conditions</li>
<li>ensure FreeBSD provides userland interfaces required by
contemporary
applications</li>
<li>implement support for machine-dependent optimized
subroutines</li>
<li>update and correct documentation and manpages</li>
<li>DTrace bug fixes</li>
<li>update the FreeBSD Valgrind port and try to upstream the
changes</li>
</ul>
<p>
Continuous Integration and Quality Assurance</p>
<p>The Foundation provides a full-time staff member who is
working on improving
our automated testing, continuous integration, and overall
quality assurance
efforts.</p>
<p>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
<a
href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">CI
weekly report</a>
on the freebsd-testing@ mailing list.</p>
<p>See the FreeBSD CI section of this report for more
information.</p>
<p>Release Engineering</p>
<p>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.</p>
<p>During the first quarter of 2019, the FreeBSD Release
Engineering team
continued providing weekly development snapshots for
13-CURRENT, 12-STABLE,
and 11-STABLE.</p>
<p>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.</p>
<p>The upcoming
<a
href="https://www.freebsd.org/releases/11.3R/schedule.html">11.3-RELEASE
schedule</a>
can be found at:
https://www.freebsd.org/releases/11.3R/schedule.html</p>
<p>FreeBSD 11.3 is currently targeted for final release in
early July 2019.</p>
<p>Please see the FreeBSD Release Engineering Team section of
this quarterly
status report for additional details surrounding the above
mentioned work.</p>
<p>Supporting FreeBSD Infrastructure</p>
<p>The Foundation provides hardware and support to improve
FreeBSD infrastructure. Last quarter, we continued
supporting FreeBSD hardware located
around the world.</p>
<p>FreeBSD Advocacy and Education</p>
<p>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.</p>
<p>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.</p>
<p>Check out some of the advocacy and education work we did
last quarter:</p>
<ul>
<li>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.</li>
</ul>
<p></p>
<ul>
<li>Sponsored and presented at SANOG33 in Thimphu, Bhutan</li>
</ul>
<p></p>
<ul>
<li>Represented FreeBSD at APRICOT 2019 in Yuseong-gu, Daejeon
South Korea</li>
</ul>
<p></p>
<ul>
<li>Sponsored the USENIX FAST conference in Boston, MA as an
Industry Partner</li>
</ul>
<p></p>
<ul>
<li>Ran our first ever FreeBSD track at
<a href="https://www.socallinuxexpo.org/scale/17x">SCALE
17x</a>, which included an
all-day
<a
href="https://www.socallinuxexpo.org/scale/17x/presentations/getting-started-freebsd">Getting
Started with FreeBSD</a>
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.</li>
</ul>
<p></p>
<ul>
<li>Sponsored, presented, and exhibited at FOSSASIA in
Singapore</li>
</ul>
<p></p>
<ul>
<li>Sponsored AsiaBSDCon 2019</li>
</ul>
<p></p>
<ul>
<li>Committed to sponsoring Rootconf, BSDCan, and EuroBSDcon</li>
</ul>
<p></p>
<ul>
<li>Created registration systems for the Aberdeen Hackathon
and the upcoming
2019 Vienna FreeBSD Security Hackathon</li>
</ul>
<p></p>
<ul>
<li>Provided FreeBSD advocacy material</li>
</ul>
<p></p>
<ul>
<li>Provided 3 travel grants to FreeBSD contributors to attend
many
of the above events.</li>
</ul>
<p>
We continued producing FreeBSD advocacy material to help
people promote
FreeBSD around the world.</p>
<p>Read more about our conference adventures in the
conference recaps and trip
reports in our
<a
href="https://www.freebsdfoundation.org/news-and-events/newsletter/">monthly
newsletters</a>.</p>
<p>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
<a
href="https://www.FreeBSDfoundation.org/journal/">www.FreeBSDfoundation.org/journal/</a>.</p>
<p>You can find out more about events we attended and
upcoming events at
<a
href="https://www.FreeBSDfoundation.org/news-and-events/">www.FreeBSDfoundation.org/news-and-events/</a>.</p>
<p>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.</p>
<p>Legal/FreeBSD IP</p>
<p>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.</p>
<p>Go to <a
href="http://www.FreeBSDfoundation.org">www.FreeBSDfoundation.org</a>
to find out
how we support FreeBSD and how we can help you!</p>
</body>
</project>
<project cat='team'>
<title>Continuous Integration</title>
<contact>
<person>
<name>Jenkins Admin</name>
<email>jenkins-admin@FreeBSD.org</email>
</person>
<person>
<name>Li-Wen Hsu</name>
<email>lwhsu@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url>
<url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url>
<url href="https://wiki.freebsd.org/Jenkins">FreeBSD Jenkins wiki</url>
<url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url>
<url href="https://github.com/freebsd/freebsd-ci">freebsd-ci Repository</url>
<url href="https://preview.tinyurl.com/y9maauwg">Tickets related to freebsd-testing@</url>
<url href="https://wiki.freebsd.org/HostedCI">Hosted CI wiki</url>
<url href="https://hackfoldr.org/freebsd-ci-report/">FreeBSD CI weekly report</url>
</links>
<body>
<p>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.</p>
<p>Starting from this quarter, we started to publish CI
weekly report at
<a
href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">freebsd-testing@</a>
mailing list. The archive is available at
<a
href="https://hackfoldr.org/freebsd-ci-report/">https://hackfoldr.org/freebsd-ci-report/</a></p>
<p>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.</p>
<p>We published the
<a
href="https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md">draft
FCP for CI policy</a>
and are ready to accept comments.</p>
<p>Please see freebsd-testing@ related tickets for more
information.</p>
<p>Work in progress:</p>
<ul>
<li>Fixing the failing test cases and builds</li>
<li>Adding drm ports building test against -CURRENT</li>
<li>Implementing automatic tests on bare metal hardware</li>
<li>Implementing the embedded testbed</li>
<li>Planning for running ztest and network stack tests</li>
<li>Help more 3rd software get CI on FreeBSD through a hosted
CI solution</li>
</ul>
<p></p>
</body>
</project>
<project cat='proj'>
<title>Security-Related changes</title>
<contact>
<person>
<name>Konstantin Belousov</name>
<email>kib@freebsd.org</email>
</person>
</contact>
<body>
<p>ASLR</p>
<p>The ASLR (Address Space Layout Randomization) patch from
<a href="https://reviews.freebsd.org/D5603">review
D5603</a> 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.</p>
<p>KPTI per-process control</p>
<p>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.</p>
<p>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.</p>
<p>Feature-control bits</p>
<p>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.</p>
<p>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.</p>
<p>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..</p>
<p>It is expected that a tool to manipulate the mask will be
provided
shortly, see <a
href="https://reviews.freebsd.org/D19290">review
D19290</a>.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>AXP803 PMIC driver update</title>
<contact>
<person>
<name>Ganbold Tsagaankhuu</name>
<email>ganbold@FreeBSD.org</email>
</person>
</contact>
<body>
<p>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 <a
href="https://www.pine64.org/pinebook/">Pinebook</a>.</p>
<p>The following updates were performed on the AXP803 driver:</p>
<ul>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
<p></p>
</body>
</project>
<project cat='proj'>
<title>Broadcom ARM64 SoC support</title>
<contact>
<person>
<name>Michal Stanek</name>
<email>mst@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
</contact>
<body>
<p>The Semihalf team continued working on FreeBSD support for
the
<a
href="https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm58712/">Broadcom
BCM5871X SoC series</a></p>
<p>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.</p>
<p>Completed since the last update:</p>
<ul>
<li>iProc PCIe root complex (internal and external buses)</li>
<li>OTP (One Time Programmable memory) driver</li>
</ul>
<p>
In progress:</p>
<ul>
<li>BNXT Ethernet support</li>
<li>Crypto engine acceleration for IPsec offloading.</li>
</ul>
<p>
Todo:</p>
<ul>
<li>Upstreaming of work. This work is expected to be
submitted/merged to HEAD in the second half of
2019.</li>
</ul>
<p></p>
</body>
<sponsor>
Juniper Networks, Inc
</sponsor>
</project>
<project cat='proj'>
<title>Capsicum</title>
<contact>
<person>
<name>Enji Cooper</name>
<email>ngie@freebsd.org</email>
</person>
<person>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>Mariusz Zaborski</name>
<email>oshogbo@FreeBSD.org</email>
</person>
<person>
<name>Bora Özarslan</name>
<email>borako.ozarslan@gmail.com</email>
</person>
</contact>
<links>
<url href="https://wiki.FreeBSD.org/Capsicum">Capsicum Wiki Page</url>
</links>
<body>
<p>Three themes for Capsicum work were:</p>
<ul>
<li>Importing Google's Capsicum test suite into FreeBSD</li>
<li>Porting and sandboxing openrsync for FreeBSD</li>
<li>Applying capsicum to additional base system utilities</li>
</ul>
<p>
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.</p>
<p>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 <tt>lstat</tt> to the Casper service.</p>
<p>Furthermore, openrsync highly depends on the <tt>fts</tt>
API. We spend
some time in optimizing <tt>fts</tt> and making it sandbox
friendly by
introducing <tt>fts_openat</tt> function and removing the
need to change the
working directory to traverse the paths. The changes to
the <tt>fts</tt> API
are now in the tests phase.</p>
<p>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 <tt>strings</tt>
is now sandboxed as a
result.</p>
<p>We also sandboxed <tt>rtsol</tt>, <tt>rtsold</tt>, and
<tt>savecore</tt>.</p>
<p>We host biweekly Capsicum calls. The notes from the
meetings are published
in FreeBSD's
<a
href="https://github.com/freebsd/meetings/tree/master/capsicum">Capsium
meeting repository</a>
on GitHub.
If you would like to join the call do not hesitate to send
us an email.</p>
</body>
</project>
<project cat='proj'>
<title>C Runtime changes</title>
<contact>
<person>
<name>Konstantin Belousov</name>
<email>kib@freebsd.org</email>
</person>
</contact>
<body>
<p>Several changes where made to the C runtime which
generally improves
the environment provided to an application.</p>
<p>Fix for libraries with initial exec TLS mode</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Another issue that somewhat mitigates mis-use of the mode
is the
<tt>DF_STATIC_TLS</tt> 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.</p>
<p>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.</p>
<p>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.</p>
<p>Use rtld malloc in libthr</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Destructors order bug</p>
<p>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
<tt>__attribute__(((destructor)))</tt>.</p>
<p>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.</p>
<p>Solution is to register rtld atexit(3) handler before main
binary init
functions are called, using new internal ABI
<tt>__libc_atexit()</tt> function.</p>
<p>It is amusing that the bug was not noticed for so many
years.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>ENA FreeBSD Driver Update</title>
<contact>
<person>
<name>Michal Krawczyk</name>
<email>mk@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
</contact>
<links>
<url href="https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README">ENA README</url>
</links>
<body>
<p>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.</p>
<p>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.</p>
<p>To do:</p>
<ul>
<li>Upstream of the ENAv2 patches</li>
</ul>
<p>
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
<a
href="https://svnweb.freebsd.org/base?view=revision&amp;revision=345371">r345371</a>
and the addition of a missing bus release method to the
nexus module
for aarch64
<a
href="https://svnweb.freebsd.org/base?view=revision&amp;revision=345373">r345373</a>.
With these changes, the ENA driver can run on A1 instances
without
any known issues.</p>
<p></p>
</body>
<sponsor>
Amazon.com Inc
</sponsor>
</project>
<project cat='proj'>
<title>FUSE</title>
<contact>
<person>
<name>Alan Somers</name>
<email>asomers@FreeBSD.org</email>
</person>
</contact>
<body>
<p>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
<a
href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&amp;known_name=fusefs&amp;list_id=289348&amp;query_based_on=fusefs&amp;query_format=advanced&amp;short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&amp;short_desc_type=anywordssubstr">buggy</a>
and out-of-date. Our implementation is about 11 years
behind.</p>
<p>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.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>Kernel ZLIB Update</title>
<contact>
<person>
<name>Yoshihiro Ota</name>
<email>ota@j.email.ne.jp</email>
</person>
</contact>
<links>
<url href="https://reviews.freebsd.org/D19706">Review D19706</url>
</links>
<body>
<p>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.</p>
<p>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.</p>
<p>This will clean up zombie programs and duplicated zlib
code.
This will also make future zlib version updates easier.</p>
<p>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.</p>
<ul>
<li>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.</li>
<li>netgraph compression/decompression
Please help testing and/or teach how to test. Netgraph
compiles
in the FreeBSD zlib version inside.</li>
<li>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?</li>
<li>zfs boot
Can we boot from gzipped file system today?</li>
<li>CTF
Checking how I can test.</li>
</ul>
<p></p>
</body>
</project>
<project cat='proj'>
<title>FreeBSD boot security improvements</title>
<contact>
<person>
<name>Michal Stanek</name>
<email>mst@semihalf.com</email>
</person>
<person>
<name>Marcin Wojtas</name>
<email>mw@semihalf.com</email>
</person>
<person>
<name>Kornel Duleba</name>
<email>mindal@semihalf.com</email>
</person>
</contact>
<links>
<url href="https://svnweb.freebsd.org/changeset/base/345830">Veriexec manifest verification in kernel</url>
<url href="https://svnweb.freebsd.org/changeset/base/345438">TPM as entropy source</url>
<url href="https://svnweb.freebsd.org/changeset/base/344840">UEFI support in libsecureboot</url>
</links>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>To do:</p>
<ul>
<li>Backport to stable branches.</li>
</ul>
<p>
Special thanks to sjg and Juniper for fruitful cooperation
around
Veriexec and the libsecureboot development.</p>
<p></p>
</body>
<sponsor>
Stormshield
</sponsor>
</project>
<project cat='proj'>
<title>LLVM's lld as the FreeBSD system linker</title>
<contact>
<person>
<name>Ed Maste</name>
<email>emaste@freebsd.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/LLD">LLD on the FreeBSD Wiki</url>
<url href="https://bugs.freebsd.org/214864">lld exp-run</url>
</links>
<body>
<p>In FreeBSD-HEAD and 12.0 the default FreeBSD system linker
(i.e., <tt>/usr/bin/ld</tt>) 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.</p>
<p>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 <tt>-fPIC</tt>
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.</p>
<p>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).</p>
<p>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 <tt>-znotext</tt> 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.</p>
<p>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.</p>
<p>Tasks:</p>
<ul>
<li>Fix freepascal/Lazarus ports with lld</li>
<li>Triage and address remaining port failures</li>
<li>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</li>
</ul>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='proj'>
<title>mlx5 Drivers Update</title>
<contact>
<person>
<name>Slava Shwartsman, Hans Petter Selasky, Konstantin Belousov</name>
<email>freebsd-drivers@mellanox.com</email>
</person>
</contact>
<links>
<url href="http://www.mellanox.com/page/products_dyn?product_family=193&mtag=freebsd_driver">Mellanox OFED for FreeBSD Documentation</url>
</links>
<body>
<p>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.</p>
<p>Following updates done in mlx5 drivers:</p>
<ul>
<li>Added support for ConnectX-6 and ConnectX-6dx devices,
which support of
up to 200Gb/s interface speeds!</li>
<li>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.</li>
<li>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.</li>
<li>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.</li>
<li>Added support for in-driver firmware updating using
mlx5tool.</li>
</ul>
<p></p>
</body>
<sponsor>
Mellanox Technologies
</sponsor>
</project>
<project cat='proj'>
<title>PCI Express Resets</title>
<contact>
<person>
<name>Konstantin Belousov</name>
<email>konstantinb@mellanox.com</email>
</person>
</contact>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p></p>
</body>
<sponsor>
Mellanox Technologies
</sponsor>
</project>
<project cat='proj'>
<title>CFT - Package Base</title>
<contact>
<person>
<name>Kris Moore</name>
<email>kmoore@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://trueos.github.io/pkgbase-docs/">Package Base CFT - FAQ</url>
</links>
<body>
<p>The TrueOS project has been working on a Package Base
implementation,
and is pleased to issue its first
<a
href="https://lists.freebsd.org/pipermail/freebsd-pkgbase/2019-April/000396.html">CFT
to the FreeBSD community</a>.</p>
<p>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
<a
href="https://github.com/freebsd/poudriere/pull/664">patch
to poudriere</a>, as well
as some minor ports enhancements, the first which is
<a href="https://reviews.freebsd.org/D20055">currently in
review</a>. For more information
on the current status, please refer to the FAQ page.</p>
<p>Additionally there will be a
<a
href="https://wiki.freebsd.org/DevSummit/201905/PackageBase">working-group
at BSDCan 2019</a>, and
we encourage porters to attend and join the discussion.</p>
<p></p>
</body>
<sponsor>
iXsystems Inc
</sponsor>
</project>
<project cat='arch'>
<title>FreeBSD/RISC-V Update</title>
<contact>
<person>
<name>Ruslan Bukin</name>
<email>br@FreeBSD.org</email>
</person>
<person>
<name>Mitchell Horne</name>
<email>mhorne@FreeBSD.org</email>
</person>
<person>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Work has continued on RISC-V port in the past quarter.</p>
<p>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.</p>
<p>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.</p>
<p>It is now possible to compile the in-tree LLVM's RISC-V
target by
setting WITH_LLVM_TARGET_RISCV=YES in /etc/src.conf. The
use of
LLVM to compile the RISC-V port is currently experimental
and
further investigation is ongoing.</p>
<p>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.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation, DARPA, AFRL
</sponsor>
</project>
<project cat='ports'>
<title>FreeBSD GNOME status report</title>
<contact>
<person>
<name>Koop Mast</name>
<email>kwm@FreeBSD.org</email>
</person>
<person>
<name>Eric Turgeon</name>
<email>ericbsd@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://freebsd.org/gnome/">GNOME FreeBSD</url>
<url href="https://github.com/freebsd/freebsd-ports-gnome">GNOME development Repo</url>
</links>
<body>
<p>Ports activity in this quarter were:</p>
<ul>
<li>The x11-toolkits/gtk30 port updated to 3.24.5 and later to
3.24.7.</li>
<li>The www/webkit2-gtk3 port was updated to 2.24.0.</li>
<li>And the old insecure webkit-gtk2 and webkit-gtk3 where
finally removed.</li>
</ul>
<p>
Work in progress, the branches are available in the GNOME
development
repo, see the link above.</p>
<ul>
<li>Eric Turgeon is working on MATE 1.22 in the
<tt>mate-1.22</tt> branch.
And is almost complete.</li>
<li>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 <tt>cinnamon</tt> branch.</li>
</ul>
<p></p>
<ul>
<li>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
<tt>gnome-3.32</tt>
branch.</li>
</ul>
<p>
People who are willing to contribute can find us on
#freebsd-gnome
on freenode.</p>
</body>
</project>
<project cat='ports'>
<title>FreeBSD KDE status report</title>
<contact>
<person>
<name>Adriaan de Groot</name>
<email>adridg@FreeBSD.org</email>
</person>
<person>
<name>Tobias C. Berner</name>
<email>tcberner@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://freebsd.kde.org/">KDE FreeBSD</url>
</links>
<body>
<p>The two biggest accomplishements this quarter were:</p>
<ul>
<li>Qt4 and all its consumers have been removed from the ports
tree.</li>
<li>www/qt5-webengine has been updated from the ancient 5.9.4
to 5.12.x by kai@</li>
</ul>
<p>
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.</p>
<p>All the kde@ maintained ports (including cmake) have been
kept up
to date with their releases.</p>
<p>The plans for the next quarter are in no particular order</p>
<ul>
<li>Cleanup PyQt ports and pyqt.mk</li>
<li>Improve qt.mk components</li>
<li>Update sddm to 0.18.x</li>
<li>Implement user management functionality in system settings
(write
non-logind backend)</li>
</ul>
<p>
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.</p>
<p></p>
</body>
</project>
<project cat='third'>
<title>sysctlmibinfo API 1.0</title>
<contact>
<person>
<name>Alfonso Sabato Siciliano</name>
<email>alfonso.siciliano@email.com</email>
</person>
</contact>
<links>
<url href="https://gitlab.com/alfix/sysctlmibinfo">gitlab.com/alfix/sysctlmibinfo</url>
</links>
<body>
<p>Port: <a
href="https://www.freshports.org/devel/libsysctlmibinfo/">devel/libsysctlmibinfo</a></p>
<p>The <tt>sysctl()</tt> 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
<tt>/sbin/sysctl</tt>,
example:</p>
<p><programlisting>
% sysctl -d kern.ostype<br/>
kern.ostype: Operating system type<br/>
% sysctl -t kern.ostype<br/>
kern.ostype: string<br/>
</programlisting></p>
<p>Primarily <tt>sysctlmibinfo</tt> wraps the undocumented
kernel interface
and provides an easy C API: <tt>sysctlmif_name()</tt>,
<tt>sysctlmif_description()</tt>,
<tt>sysctlmif_info()</tt>,
<tt>sysctlmif_label()</tt>,
<tt>sysctlmif_nextnode()</tt> and
<tt>sysctlmif_nextleaf()</tt>, to retrieve
the info of a 'property'.</p>
<p>Moreover <tt>sysctlmibinfo</tt> provides a high level API:
defines a
<tt>struct sysctlmif_object</tt> and has some function:
<tt>sysctlmif_filterlist()</tt>,
<tt>sysctlmif_grouplist()</tt> and
<tt>sysctlmif_tree()</tt>, to build lists and trees of
objects.</p>
<p>You can use this library to quickly build a custom
<tt>sysctl</tt> utility.
For example, the core of <tt>deskutils/sysctlview</tt> (a
graphical explorer
for the sysctl MIB Tree) is just a call to
<tt>sysctlmif_tree()</tt> and
a visit to the resulting tree to show its
<tt>sysctlmif_object</tt> nodes.</p>
<p>Note, actually a 'property' is an OID of the sysctl MIB,
it is
implemented by a <tt>struct sysctl_oid</tt> defined in
<tt>sys/sysctl.h</tt>.</p>
</body>
</project>
<project cat='third'>
<title>sysctlview 1.0</title>
<contact>
<person>
<name>Alfonso Sabato Siciliano</name>
<email>alfonso.siciliano@email.com</email>
</person>
</contact>
<links>
<url href="https://www.gitlab.com/alfix/sysctlview">gitlab.com/alfix/sysctlview</url>
</links>
<body>
<p>Port: <a
href="https://www.freshports.org/deskutils/sysctlview/">deskutils/sysctlview</a></p>
<p>The FreeBSD's kernel maintains a Management Information
Base where
the objects are properties to tuning the system using the
<tt>sysctl()</tt> syscall and the <tt>/sbin/sysctl</tt>
utility. The <tt>sysctlview</tt>
utility is a "graphical sysctl MIB explorer", it depends
on <tt>gtkmm</tt>
(to build a GUI) and <tt>sysctlmibinfo</tt> (to retrieve
the info from the
kernel).</p>
<p>The version 1.0 provides two "TreeView":</p>
<ul>
<li>"Main" to show 'name', 'description', 'type', 'format' and
'value'</li>
<li>"Flags" to show 'name' and a column for each 'flag'
defined in <tt>sys/sysctl.h</tt></li>
</ul>
<p>
The rows are "clickable" to display others info (e.g.,
'label').
Currently <tt>sysctlview</tt> can show numeric and string
values, the
support for some opaque value will be added in the future.</p>
</body>
</project>
<project cat='third'>
<title>Fuzzing FreeBSD with syzkaller</title>
<contact>
<person>
<name>Mark Johnston</name>
<email>markj@FreeBSD.org</email>
</person>
<person>
<name>Andrew Turner</name>
<email>andrew@FreeBSD.org</email>
</person>
<person>
<name>Michael Tuexen</name>
<email>tuexen@FreeBSD.org</email>
</person>
<person>
<name>Ed Maste</name>
<email>emaste@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://github.com/google/syzkaller">syzkaller</url>
</links>
<body>
<p>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.</p>
<p>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
<a href="https://syzkaller.appspot.com/freebsd">FreeBSD
target</a> was recently added.
Subscribe to the
<a
href="https://groups.google.com/forum/#!forum/syzkaller-freebsd-bugs">syzkaller-freebsd-bugs</a>
Google Group to receive notifications for newly discovered
bugs.</p>
<p>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.</p>
<p>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
<a
href="https://github.com/google/syzkaller/pull/1150">PR</a>
for the
implementation.</p>
<p>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.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='third'>
<title>University of Waterloo Co-operative Education Students</title>
<contact>
<person>
<name>Ed Maste</name>
<email>emaste@freebsd.org</email>
</person>
</contact>
<body>
<p>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.</p>
<p>Gerald Aryeetey is a 2nd year Computer Engineering
student. Gerald
started looking at a FreeBSD tool chain issue - our static
library
archiver (<literal>ar</literal>) did not read or write archives in the
64-bit format.
Gerald submitted a
<a
href="https://github.com/libarchive/libarchive/pull/1116">libarchive
change</a>
to support 64-bit archives followed by
<a href="https://reviews.freebsd.org/D19814">change to
FreeBSD's ar</a>
to add 64-bit support.</p>
<p>Gerald later looked at a number of <tt>freebsd-update</tt>
issues in FreeBSD's
bugzilla database, and submitted many fixes. Around a
dozen have been
committed to FreeBSD, and more are in review.</p>
<p>Gerald also worked on the
<a
href="https://github.com/freebsdfoundation/hardware-ci">FreeBSD
Foundation's hardware continuous integration</a>
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.</p>
<p>For his final project Gerald intends to write a device
driver for the
<a
href="https://www.microchip.com/wwwproducts/en/LAN7430">Microchip
LAN743x PCIe NIC</a>.</p>
<p>Bora Özarslan 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 <tt>readelf</tt>
(from the
<a
href="https://sourceforge.net/p/elftoolchain/wiki/Home/">ELF
Tool Chain</a> project).</p>
<p>Bora developed a
<a href="https://reviews.freebsd.org/D19290">tool</a> 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.</p>
<p>Bora continued investigating security topics, looking at
applying
<a href="https://reviews.freebsd.org/D19407">Capsicum
sandboxing</a> to
Kristaps' BSD licensed rsync implementation,
<a
href="https://github.com/kristapsdz/openrsync">openrsync</a>.
This work required first implementing
<a
href="https://reviews.freebsd.org/D19548">fileargs_lstat</a>
support in <tt>cap_fileargs</tt>
(which as now been committed) as well as changes to the
<tt>fts</tt> directory hierarchy routines (which have not
yet been committed to
FreeBSD).</p>
<p>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.</p>
<p></p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
</project>
<project cat='third'>
<title>FreeBSD Wiki Apple Intel Mac mini update</title>
<contact>
<person>
<name>Trevor Roydhouse</name>
<email>fbsdwiki@gmx.net</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/IntelMacMini">FreeBSD Wiki</url>
</links>
<body>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Future tasks:</p>
<ul>
<li>Create and test more patches for asmc(4) to cover all
Intel Mac minis</li>
<li>Provide more information for 2006, 2012, 2014 and 2018 Mac
minis</li>
<li>Instructions for dual boot (macOS/FreeBSD) installations</li>
</ul>
<p></p>
</body>
</project>
</report>