Differential D20446 Diff 58042 en_US.ISO8859-1/htdocs/news/status/report-2019-01-2019-03.xml

Changeset View

Standalone View

en_US.ISO8859-1/htdocs/news/status/report-2019-01-2019-03.xml

This file was added.

				<?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: head/en_US.ISO8859-1/htdocs/news/status/report-template.xml 51132 2017-10-19 01:38:11Z bjk $ -->
				<!-- 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>%%START%%-%%STOP%%</month>

				<year>%%YEAR%%</year>
				</date>

				<section>
				<title>Introduction</title>

				<p><strong>This is a draft of the %%START%%–%%STOP%% %%YEAR%%
				status report. Please check back after it is finalized, and
				an announcement email is sent to the &os;-Announce mailing
				list.</strong></p>

				<?ignore
				<p>This report covers &os;-related projects between %%START%% and
				%%STOP%% %%YEAR%%. This is the %%NUM%% of four reports planned for
				%%YEAR%%.</p>

				<p>The %%NUM%% quarter of %%YEAR%% was another productive quarter for
				the &os; project and community. [...]</p>

				<p>Thanks to all the reporters for the excellent work!</p>

				<p>The deadline for submissions covering the period from %%STARTNEXT%%
				to %%STOPNEXT%% %%YEARNEXT%% is %%DUENEXT%%, %%YEARNEXT%%.</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>kern</name>

				<description>Kernel</description>

				<p>Updates to kernel subsystems/features, driver support,
				filesystems, and more.</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>bin</name>

				<description>Userland Programs</description>

				<p>Changes affecting the base system and programs in it.</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>doc</name>

				<description>Documentation</description>

				<p>Noteworthy changes in the documentation tree or new external
				books/documents.</p>
				</category>

				<category>
				<name>misc</name>

				<description>Miscellaneous</description>

				<p>Objects that defy categorization.</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>

				bcrUnsubmitted Not Done Inline Actions This could probably be pulled up into the previous line. Maybe there is some way of auto-formatting? bcr: This could probably be pulled up into the previous line. Maybe there is some way of auto…
				allanjudeUnsubmitted Not Done Inline Actions It doesn't impact how the content renders, so I don't think it is worth spending time on allanjude: It doesn't impact how the content renders, so I don't think it is worth spending time on
				<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>
				bcrUnsubmitted Done Inline Actions This should probably be a <a href=..> tag. bcr: This should probably be a <a href=..> tag.

				<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
				bcrUnsubmitted Done Inline Actions s/creates chicken/creates a chicken/ bcr: s/creates chicken/creates a chicken/
				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
				bcrUnsubmitted Done Inline Actions s/of code/of the code/ bcr: s/of code/of the code/
				with the newer version of zlib as is. The unzip code will
				bcrUnsubmitted Done Inline Actions s/as with/with/ bcr: s/as with/with/
				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>
				bcrUnsubmitted Not Done Inline Actions Each person should have their own name entry. bcr: Each person should have their own name entry.
				traszAuthorUnsubmitted Not Done Inline Actions Not sure how to handle this one, to be honest - they all have a common email address for this project. trasz: Not sure how to handle this one, to be honest - they all have a common email address for this…
				<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
				bcrUnsubmitted Done Inline Actions The link does not work here. The [ and ] need to be removed and put into the <a href=...></a> tag as description. bcr: The link does not work here. The [ and ] need to be removed and put into the <a href=...></a>…
				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>
				bcrUnsubmitted Done Inline Actions Same link-problem here. I guess it was submitted as a different doc format (markdown?) which could not be translated into docbook by the tool. bcr: Same link-problem here. I guess it was submitted as a different doc format (markdown?) which…
				traszAuthorUnsubmitted Done Inline Actions Nah, it's just because the md2docbook converter is crappy. It's trivially easy to work around, I just hadn't noticed it. trasz: Nah, it's just because the md2docbook converter is crappy. It's trivially easy to work around…

				</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>

				bcrUnsubmitted Done Inline Actions s/where/were/ bcr: s/where/were/
				<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>
				bcrUnsubmitted Done Inline Actions Another link problem here with [cinnamon]. bcr: Another link problem here with [cinnamon].
				traszAuthorUnsubmitted Done Inline Actions Strangely, this one is not a link at all - I've just removed the [brackets]. trasz: Strangely, this one is not a link at all - I've just removed the [brackets].

				<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>
				bcrUnsubmitted Done Inline Actions And again here... Maybe searching for [ and ] turns up other results like this. bcr: And again here... Maybe searching for [ and ] turns up other results like this.
				traszAuthorUnsubmitted Done Inline Actions Done, found one more example of this. trasz: Done, found one more example of this.
				</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
				bcrUnsubmitted Not Done Inline Actions The `are not properly translated into docbook yet. A <programlisting> comes to mind... bcr: The ```are not properly translated into docbook yet. A <programlisting> comes to mind...
				traszAuthorUnsubmitted Not Done Inline Actions There's something weird going on here - even with <programlisting> it looks weird. I'll investigate some more. trasz: There's something weird going on here - even with <programlisting> it looks weird. I'll…
				kern.ostype: Operating system type
				% sysctl -t kern.ostype
				kern.ostype: string
				</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
				bcrUnsubmitted Not Done Inline Actions s/system call/systemcall/ bcr: s/system call/systemcall/
				traszAuthorUnsubmitted Done Inline Actions Erm... I think 'system call' is the right term. I've also seen 'syscall', but not really 'systemcall'. trasz: Erm... I think 'system call' is the right term. I've also seen 'syscall', but not really…
				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
				bcrUnsubmitted Done Inline Actions Replace the `'s with <literal>. bcr: Replace the `'s with <literal>.
				<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>