Differential D22323 Diff 64656 report-2019-07-2019-09.xml

Changeset View

Standalone View

report-2019-07-2019-09.xml

				<?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>07-09</month>

				<year>2019</year>
				</date>

				<section>
				<title>Introduction</title>
				<p>Here is the third quarterly status report for 2019.</p>

				<p>This quarter the reports team has been more active than usual thanks
				to a better organization: calls for reports and reminders have been
				sent regularly, reports have been reviewed and merged quickly (I would
				like to thank debdrup@ in particular for his reviewing work).</p>
				<p>Efficiency could still be improved with the help of our community.
				In particular, the quarterly team has found that many reports have
				arrived in the last days before the deadline or even after. I would
				like to invite the community to follow the guidelines below that
				can help us sending out the reports sooner.</p>
				<ul>
				<li>Send a first draft of your report when you receive the first call
				for reports (1 month before the deadline).</li>
				<li>Update your report, if needed, when you receive reminders: you will
				normaly receive two (2 weeks and 1 week before the deadline).</li>
				<li>If after the deadline you still have some more updates ask the team
				(either on IRC via #freebsd-wiki or send an email at monthly@) to
				wait for you if you feel that they are urgent, otherwise start
				putting them in a draft for the next quarter.</li></ul>

				<p>Starting from next quarter, all quarterly status reports will be
				prepared the last month of the quarter itself, instead of the first
				month after the quarter's end. This means that deadlines for
				submitting reports will be the 1st of January, April, July and
				October.</p>
				<p>Next quarter will then be a short one, covering the months of November
				and December only and the report will probably be out in mid January.</p>

				<p>-- Lorenzo Salvadore</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>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 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>

				<ul>
				<li>Core has provisionally accepted the BSD+patent license for
				use in some cases.
				The Core Team must approve the import of new BSD+Patent
				licensed components or
				the change of license of existing components to the
				BSD+Patent License.
				<br/>
				https://opensource.org/licenses/BSDplusPatent</li>

				<li>Kernel Pseudo Random Number Generator (PRNG)
				maintainership was updated to
				reduce the contribution barrier for committers who have
				demonstrated
				competence in this part of the tree.</li>
				<li>Core approved a source commit bit for Paweł Biernacki.
				Konstantin Belousov
				<kib@> will mentor Paweł and Mateusz Guzik
				<mjg@> will be co-mentor.</li>
				<li>The Core-initiated Git Transition Working Group met over
				the last quarter,
				however a report is still forthcoming. Discussions will
				continue in the
				fourth quarter of 2019. There are many issues to resolve
				including how to
				deal with contrib/, whether to re-generate hashes in the
				current Git
				repository, and how to best implement commit testing.</li>
				</ul>

				</body>

				</project>

				<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/announce.html">FreeBSD 11.3-RELEASE announcement</url>
				<url href="https://www.freebsd.org/releases/12.1R/schedule.html">FreeBSD 12.1-RELEASE schedule</url>
				<url href="https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.1/">FreeBSD 12.1-RELEASE BETA/RC builds</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>

				allanjudeUnsubmitted Done Inline Actions It looks like the markdown parser goofed, or the markdown this was generated from was missing a line break or two. Obviously '`FreeBSD Release Engineering Team`' is meant to be the title of the next section allanjude: It looks like the markdown parser goofed, or the markdown this was generated from was missing a…
				<p>During the third quarter of 2019, the FreeBSD Release
				Engineering team
				finished the 11.3-RELEASE cycle, with the final release
				build started on
				July 5th and the official announcement sent on July 9th.</p>

				<p>FreeBSD 11.3-RELEASE is the fourth release from the
				<i>stable/11</i> branch,
				building on the stability and reliability of 11.2-RELEASE.</p>

				<p>The FreeBSD Release Engineering Team also started work on
				the upcoming
				12.1-RELEASE, which started September 6th. This release
				cycle is the
				first "freeze-less" release from the Subversion
				repository, and the test bed
				for eliminating the requirement of a hard code freeze on
				development branches.
				Commits to the <i>releng/12.1</i> branch still
				require explicit approval from
				the Release Engineering Team, however.</p>

				<p>At present, there have been three BETA builds, and so far,
				two RC builds, with
				the final 12.1-RELEASE build scheduled for November 4th.</p>

				<p>Additionally throughout the quarter, several development
				snapshots builds
				were released for the <i>head</i> and
				<i>stable/11</i> branches; snapshots for
				<i>stable/12</i> were released as well although
				not during the 12.1-RELEASE cycle.</p>

				<p>Much of this work was sponsored by Rubicon Communications,
				LLC (Netgate)
				and the FreeBSD Foundation.</p>

				</body>

				</project>

				<project cat='team'>
				allanjudeUnsubmitted Done Inline Actions I assume there were snapshots of stable/12 allanjude: I assume there were snapshots of stable/12
				salvadoreAuthorUnsubmitted Done Inline Actions Indeed it seems so: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.1/?C=M&O=D Should I just add <tt>stable/12<tt> or ask releng@ ? salvadore: Indeed it seems so: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.1/?C=M&O=D Should…
				<title>FreeBSD Security Team</title>

				<contact>
				<person>
				<name>Security Team</name>
				<email>secteam@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://www.freebsd.org/security/">FreeBSD security information</url>
				</links>

				<body>
				<p>Several members of the security team met at the Vendor
				Summit in October to
				formalize team structure dedicated for architecture and
				crypto engineering in
				addition to the existing product security incident
				response function.</p>

				<p>Since June we have started having fortnightly conference
				calls to discuss
				important issues and to collaborate closely on advisories
				and errata notices in
				the pipeline.</p>

				<ul>
				<li>Security advisories sent out in 2019-Q3: 7</li>

				<li>Errata Notices sent out in 2019-Q3: 5</li>
				</ul>

				</body>

				</project>

				<project cat='team'>
				<title>Cluster Administration Team</title>

				<contact>
				<person>
				<name>Cluster Administration Team</name>
				<email>clusteradm@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>The FreeBSD Cluster Administration Team consists of the
				people responsible for administering the machines
				that the Project relies on for its distributed
				work and communications to be synchronised. In
				this quarter, the team has worked on the
				following:</p>

				<ul>
				<li>Change IPv6 address in TWN site.</li>

				<li>Solved hardware issues in KWC site (with hrs@).</li>

				<li>Moved remaining infrastructure from the YSV (Yahoo!) site
				to NYI (New York Internet) (peter@).</li>

				<ul><li>YSV hosted most of FreeBSD.org between 2000 and 2019.</li></ul>

				<li>Installed new machines for portmgr@ courtesy of the
				FreeBSD Foundation.</li>

				<li>Resolved outtages (thanks uqs@) with GitHub exporter,
				Bugzilla and hg-beta (thanks bapt@).</li>

				<li>PowerPC64 servers are online (power8) building pkgs and
				reference hosts.</li>

				<li>Ongoing systems administration work:</li>

				<ul><li>Creating accounts for new committers.</li>

				<li>Backups of critical infrastructure.</li>

				<li>Keeping up with security updates in 3rd party software.</li></ul>
				</ul>

				<p>
				Work in progress:</p>

				<ul>
				<li>Review the service jails and service administrators
				operation.</li>

				<li>South Africa Mirror (JINX) in progress.</li>

				<li>NVME issues on PowerPC64 Power9 blocking dual socket
				machine from being used as pkg builder.</li>

				<li>Drive upgrade test for pkg builders (SSDs) courtesy of the
				FreeBSD Foundation.</li>

				<li>Boot issues with Aarch64 reference machines.</li>

				<li>New NYI.net sponsored colocation space in Chicago-land
				area.</li>

				<li>Setup new host for CI staging environment.</li>
				</ul>

				</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://hackmd.io/@FreeBSD-CI">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 committed changes
				can be successfully built, then 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. The details
				are of these efforts
				are available in the weekly CI reports.</p>

				<p>We had a testing working group at the <a
				href="https://wiki.freebsd.org/DevSummit/201909">201909
				DevSummit</a>
				lwhsu@ has presented the Testing/CI project status and
				"how to work with the FreeBSD CI system", slides
				are available at the DevSummit page.
				Some contents have been migrated to
				https://wiki.freebsd.org/Jenkins/Debug , extending
				is welcomed.</p>

				<p>We continue publishing CI Weekly Report and moved the
				archive to https://hackmd.io/@FreeBSD-CI</p>

				<p>Work in progress:</p>
				allanjudeUnsubmitted Done Inline Actions We had testing working group at the allanjude: We had testing working group at the

				<ul>
				<li>Collecting and sorting CI tasks and ideas at
				allanjudeUnsubmitted Done Inline Actions project allanjude: project
				https://hackmd.io/bWCGgdDFTTK_FG0X7J1Vmg</li>

				<li>Setup the CI stage environment and put the experimental
				jobs on it</li>

				<li>Extending and publishing the embedded boards testbed</li>

				<li>Implementing automatic tests on bare metal hardware</li>

				<li>Adding drm ports building test against -CURRENT</li>

				<li>Testing and merging pull requests at
				https://github.com/freebsd/freebsd-ci/pulls</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>
				Please see freebsd-testing@ related tickets for more WIP
				information.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</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. The
				Foundation purchases
				and supports hardware to improve and maintain FreeBSD
				infrastructure and
				provides resources to improve security and quality
				assurance 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>Partnerships and Commercial User Support
				We help facilitate collaboration between commercial users
				and FreeBSD
				developers. We also meet with companies to discuss their
				needs and bring
				that information back to the Project. In Q3, Ed Maste and
				Deb Goodkin met
				with a few commercial users in the US. It is not only
				beneficial for the
				above, but it also helps us understand some of the
				applications where
				FreeBSD is used. We were also able to meet with a good
				number of commercial
				users at vBSDCon and EuroBSDCon. These venues provide an
				excellent
				opportunity to meet with commercial and individual users
				and contributors
				to FreeBSD.</p>

				<p>Fundraising Efforts
				Our work is 100% funded by your donations. We are
				continuing to work hard
				to get more commercial users to give back to help us
				continue our work
				supporting FreeBSD. More importantly, we'd like to thank
				our individual
				donors for making $10-$1,000 donations last quarter, for
				more than $16,000!</p>

				<p>Please consider
				<a href="https://www.FreeBSDfoundation.org/donate/">making
				a donation</a> to help us
				continue and increase our support for FreeBSD!</p>

				<p>We also have the Partnership Program, to provide more
				benefits for our
				larger commercial donors. Find out more information at
				<a
				href="https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/">www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/</a>
				and share with your companies.</p>

				<p>OS Improvements
				The Foundation supports software development projects to
				improve the FreeBSD
				operating system through our full time technical staff,
				contractors, and
				project grant recipients. They maintain and improve
				critical kernel
				subsystems, add new features and functionality, and fix
				problems.</p>

				<p>Over the last quarter there were 345 commits to the
				FreeBSD base system
				repository sponsored by the FreeBSD Foundation - this
				represents about
				one fifth of all commits during this period. Many of these
				projects have
				their own entries in this quarterly report (and are not
				repeated here).</p>

				<p>Foundation staff member Konstantin Belousov committed many
				improvements to
				multiple kernel subsystems, as well as low-level 32-bit
				and 64-bit x86
				infrastructure. These included fixes for robust mutexes,
				unionfs, the
				out of memory (OOM) handler, and per-cpu allocators.</p>

				<p>Additional work included fixes for security issues and
				introduction and
				maintenance of vulnerability mitigations, and improving
				POSIX conformance.</p>

				<p>Ed Maste committed a number of minor security bug fixes
				and improvements,
				as well as the first iteration of a tool for editing the
				mitigation control
				ELF note. Additional work included effort on build
				infrastructure and the
				tool chain.</p>

				<p>Clang's integrated assembler (IAS) is now used more
				widely, as part of the
				path to retiring the assembler from GNU binutils 2.17.50.
				The readelf tool
				now decodes some additional ELF note information.</p>

				<p>Ed also enabled the Linuxulator (Linux binary support
				layer) on arm64, and
				added a trivial implementation of the renameat2 system
				call (handling common
				options).</p>

				<p>Mark Johnston added Capsicum support to a number of ELF
				Tool Chain utilities,
				and committed a number of other Capsicum kernel and
				userland fixes.</p>

				<p>Mark worked on a number of changes related to security
				improvements, including
				integration and support of the Syzkaller automated system
				call fuzzer, and
				fixing issues identified by Syzkaller. Other changes
				included addressing
				failures caused by refcount wraparound, improvements to
				the <tt>prot_max</tt> memory
				protection. Other work included NUMA, locking, kernel
				debugging, RISC-V and
				arm64 kernel improvements.</p>

				<p>Edward Napierala continued working on Linuxulator
				improvements over the
				quarter. The primary focus continued to be tool
				improvements - strace is now
				more usable for diagnosing issues with Linux binaries
				running under the
				Linuxulator. That said, as with previous work a number of
				issues have been
				fixed along the way. These are generally minor issues with
				a large impact -
				for example, every binary linked against up-to-date glibc
				previously
				segfaulted on startup. This is now fixed.</p>

				<p>Continuous Integration and Quality Assurance
				The Foundation provides a full-time staff member who is
				working on improving
				our automated testing, continuous integration, and overall
				quality assurance
				efforts.</p>

				<p>During the third quarter of 2019, Foundation staff
				continued to improve the
				project's CI infrastructure, worked with contributors to
				fix the failing build
				and test cases, and worked with other teams in the Project
				for their testing
				needs. We added several new CI jobs and worked on getting
				the hardware
				regression testing lab ready.</p>

				<p>Li-Wen Hsu gave presentations "Testing/CI status update"
				and "How to work with
				the FreeBSD CI system" at the
				<a href="https://wiki.freebsd.org/DevSummit/201909">201909
				DevSummit</a>.
				Slides are available at the DevSummit page.</p>

				<p>We continue publishing the CI weekly report on the
				<a
				href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">freebsd-testing@</a>.
				mailing list, and an <a
				href="https://hackmd.io/@freebsd-ci">archive</a>
				is available.</p>

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

				<p>Supporting FreeBSD Infrastructure
				The Foundation provides hardware and support to improve
				the FreeBSD
				infrastructure. Last quarter, we continued supporting
				FreeBSD hardware
				located around the world.</p>

				<p>FreeBSD Advocacy and Education
				A large part of our efforts are dedicated to advocating
				for the Project.
				This includes promoting work being done by others with
				FreeBSD; producing
				advocacy literature to teach people about FreeBSD and help
				make the path to
				starting using FreeBSD or contributing to the Project
				easier; and attending
				and getting other FreeBSD contributors to volunteer to run
				FreeBSD events,
				staff FreeBSD tables, and give FreeBSD presentations.</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>Sponsored USENIX 2019 Annual Technical Conference as an
				Industry Partner</li>

				<li>Represented FreeBSD at OSCON 2019 in Portland, OR</li>

				<li>Represented FreeBSD at COSCUP 2019 in Taiwan</li>

				<li>Presented at the Open Source Summit, North American in San
				Diego, CA</li>

				<li>Executive Director Deb Goodkin was interviewed by TFiR
				https://www.freebsdfoundation.org/news-and-events/latest-news/tfir-interview-freebsd-meets-linux-at-the-open-source-summit/</li>

				<li>Sponsored FreeBSD Hackathon at vBSDcon 2019 in Reston, VA</li>

				<li>Sponsored the attendee bags and attended vBSDcon 2019 in
				Reston VA</li>

				<li>Represented FreeBSD at APNIC-48 in Chiang Mai, Thailand</li>

				<li>Represented FreeBSD at MNNOG-1 in Ulaanbaatar, Mongolia</li>

				<li>Served as an administrator for the Project’s Google Summer
				of Code Session. See the Google Summer of Code
				section of this report for more information.</li>

				<li>Sponsored FreeBSD Developers Summit at EuroBSDCon in
				Lillehammer, Norway</li>

				<li>Sponsored and attended EuroBSDcon 2019 in Lillehammer,
				Norway</li>

				<li>Applied and was accepted for a FreeBSD Miniconf at
				linux.conf.au, in Gold Coast, Australia, Jan 14,
				2020</li>

				<li>Our FreeBSD talk was accepted at seaGL, Seattle, WA,
				November 15 and 16.</li>
				</ul>

				<p>
				We continued producing FreeBSD advocacy material to help
				people promote
				FreeBSD. Learn more about our recent efforts to advocate
				for FreeBSD
				around the world:
				https://www.freebsdfoundation.org/blog/freebsd-around-the-world/</p>

				<p>Our Faces of FreeBSD series is back. Check out the latest
				post:
				<a
				href="https://www.freebsdfoundation.org/blog/faces-of-freebsd-2019-roller-angel/">Roller
				Angel</a>.</p>

				<p>Read more about our conference adventures in the
				conference recaps and trip
				reports in our monthly newsletters:

				https://www.freebsdfoundation.org/news-and-events/newsletter/</p>

				<p>We help educate the world about FreeBSD by publishing the
				professionally
				produced FreeBSD Journal. As we mentioned previously, the
				FreeBSD Journal
				is now a free publication. Find out more and access the
				latest issues at
				https://www.FreeBSDfoundation.org/journal/.</p>

				<p>You can find out more about
				<a
				href="https://www.FreeBSDfoundation.org/news-and-events/">events
				we attended and upcoming events</a>.</p>

				<p>We opened our official FreeBSD Swag Store. Get stickers,
				shirts, mugs and
				more at <a
				href="https://www.zazzle.com/store/shopfreebsd">ShopFreeBSD</a>.</p>

				<p>We have continued our work with a new website developer to
				help us improve
				our website. Work has begun to make it easier for
				community members to find
				information and to make the site more efficient.</p>

				<p>Legal/FreeBSD IP
				The Foundation owns the FreeBSD trademarks, and it is our
				responsibility to
				protect them. We also provide legal support for the core
				team to investigate
				questions that arise.</p>

				<p>Go to http://www.FreeBSDfoundation.org to find out how we
				support FreeBSD and
				how we can help you!</p>

				</body>

				</project>

				<project cat='team'>
				<title>FreeBSD Graphics Team status report</title>

				<contact>
				<person>
				<name>FreeBSD Graphics Team</name>
				<email>x11@freebsd.org</email>
				</person>
				<person>
				<name>Niclas Zeising</name>
				<email>zeising@freebsd.org</email>
				</person>
				</contact>

				<links>
				<url href="https://github.com/FreeBSDDesktop">Project GitHub page</url>
				</links>

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

				<p>During the last period, several changes have been made,
				but most of them has
				been behind the scene.
				We have also worked on general clean up of old xorg ports
				that have been
				deprecated upstream.</p>

				<p>The ports infrastructure for xorg ports and ports that
				depend on xorg ports have
				been updated.
				We have switched <tt>USE_XORG</tt> and <tt>XORG_CAT</tt>
				to use the <tt>USES</tt> framework, instead
				of the old way of including <tt>bsd.xorg.mk</tt> from
				<tt>bsd.port.mk</tt>.
				This infrastructure work has been fairly substantial, and
				new ports depending on
				xorg ports should add <tt>USES=xorg</tt> to their
				makefiles.
				As part of this <tt>bsd.xorg.mk</tt> was split up, and the
				<tt>XORG_CAT</tt> part was split
				out to <tt>USES=xorg-cat</tt>.
				This is used for the xorg ports themselves, and sets up a
				common environment for
				building all xorg ports.
				In addition, framework for pulling xorg ports directly
				from freedesktop.org
				gitlab was added, which will make improve development and
				testing, since it
				makes it possible to create ports of unreleased versions.
				Further improvements in this area includes framework for
				using meson instead of
				autotools for building xorg ports.
				This is still a work in progress.</p>

				<p>We have also worked to clean up and deprecate several old
				xorg ports and
				libraries.
				Some of these ports have already been removed, and some
				are still waiting on
				removal after a sufficient deprecation period.
				Most notably amongst the deprecations are
				<tt>x11/libXp</tt>, which required to fix
				several dependencies.
				Several other old libraries have also been deprecated,
				such as <tt>x11/Xxf86misc</tt>,
				<tt>x11-fonts/libXfontcache</tt> and
				<tt>graphics/libGLw</tt>.
				Some applications and drivers have also been deprecated
				during the period.
				With the remaining removals in this area, we should be up
				to speed with
				deprecations upstream.
				We are currently investigating if there are new software
				added upstream that we
				need to port to FreeBSD.</p>

				<p>We have also continued our regularly scheduled bi-weekly
				meetings.</p>

				<p>People who are interested in helping out can find us on
				the x11@FreeBSD.org
				mailing list, or on our gitter chat: <a
				href="https://gitter.im/FreeBSDDesktop/Lobby">https://gitter.im/FreeBSDDesktop/Lobby</a>.
				We are also available in #freebsd-xorg on EFNet.</p>

				<p>We also have a team area on GitHub where our work
				repositories can be found:
				<a
				href="https://github.com/FreeBSDDesktop">https://github.com/FreeBSDDesktop</a></p>

				</body>

				</project>

				<project cat='proj'>
				<title>Google Summer of Code 2019</title>

				<contact>
				<person>
				<name>Summer of Code Admins</name>
				<email>soc-admins@freebsd.org</email>
				</person>
				</contact>

				<links>
				<url href="https://wiki.freebsd.org/SummerOfCode2019Projects">2019 Summer of Code Project Wikis</url>
				<url href="https://summerofcode.withgoogle.com/archive/2019/organizations/6504969929228288/">2019 Summer of Code Projects</url>
				</links>

				<body>
				<p>The FreeBSD Project is pleased to have participated in
				Google Summer of Code 2019 marking our 14th year of
				participation.
				This year we had six successful projects:</p>

				<ul>
				<li><i>Dual-stack ping command</i> by Ján Sučan</li>

				<li><i>Firewall test suite</i> by Ahsan Barkati</li>

				<li><i>Kernel sanitizers</i> by Costin Carabaș</li>

				<li><i>MAC policy on IP addresses for FreeBSD
				Jail</i> by Shivank Garg</li>

				<li><i>Separation of ports build process from local
				installation</i> by Theron Tarigo</li>

				<li><i>Virtual memory compression</i> by
				Paavo-Einari Kaipila</li>
				allanjudeUnsubmitted Done Inline Actions Are these meant to each have a * after them, or is that some markdown formatting that did not survive the translation process? allanjude: Are these meant to each have a * after them, or is that some markdown formatting that did not…
				</ul>

				<p>
				We thank Google for the opportunity to work with these
				students and hope
				they continue to work with FreeBSD in the future.</p>

				</body>

				<sponsor>
				Google Summer of Code
				</sponsor>

				</project>

				<project cat='proj'>
				<title>GSoC'19 Project - MAC policy on IP addresses in Jail: mac_ipacl</title>

				<contact>
				<person>
				<name>Shivank Garg</name>
				<email>shivank@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://reviews.freebsd.org/D20967">FreeBSD's Phabricator Differential Link</url>
				<url href="https://github.com/freebsd/freebsd/compare/master...shivankgarg98:shivank_MACPolicyIPAddressJail">Github Diff Link</url>
				<url href="https://wiki.freebsd.org/SummerOfCode2019Projects/MACPolicyIPAddressJail">Project Wiki Page</url>
				</links>

				<body>
				<p><b>About -</b> With the introduction of VNET(9)
				in FreeBSD, Jails are free to
				set their IP addresses. However, this privilege may need
				to be limited by
				the host as per its need for multiple security reasons.
				This project uses mac(9) for an access control framework
				to impose
				restrictions on FreeBSD jails according to rules defined
				by the root of the
				host using sysctl(8). It involves the development of a
				dynamically loadable
				kernel module (mac_ipacl) based on The TrustedBSD MAC
				Framework to
				implement a security policy for configuring the network
				allanjudeUnsubmitted Done Inline Actions Markdown formatting has fallen apart here This entire report item is mis-formatted all over the place. allanjude: Markdown formatting has fallen apart here This entire report item is mis-formatted all over…
				stack.
				This project allows the root of the host to define the
				policy rules to
				limit the root of a jail to a set of IP (v4 or v6)
				addresses and/or subnets
				for a set of interfaces.</p>

				<p>Features this new MAC policy module are:</p>

				<ul>
				<li>The host can define one or more lists of IP
				addresses/subnets
				for the jail to choose from.</li>

				<li>The host can restrict the jail from setting certain IP
				addresses or
				prefixes (subnets).</li>

				<li>The host can restrict this privilege to a few network
				interfaces.</li>
				</ul>

				<p>
				<b>Implementation -</b> The mac_ipacl module is
				a loadable kernel module. It
				implements mac checks in netinet/in.c and netinet6/in6.c
				to check the IP
				addresses requested by jail. The idea to implement these
				checks at these
				places comes from the fact that SIOCAIFADDR (for IPv4) and
				SIOCAIFADDR_IN6 (for IPv6) ioctl handlers are defined for
				adding the IP
				addresses to an interface. This is used by ifconfig (in
				userspace) for
				setting the IP address. The MAC Framework acts as
				multiplexer between the
				netinet and the module. The requested IP and the
				credentials are checked
				with the rules in mac_ipacl and output is returned
				accordingly to netinet.
				The module can be tuned with various sysctl and similarly,
				policy rules are
				also be defined with sysctl.</p>

				<p><b>TestSuite -</b> Test scripts integrated with
				kyua and ATF are included with
				the module.</p>

				<p><b>Using the module -</b> I have written a man
				page for the module. Please
				refer to the mac_ipacl(4) for using the new MAC module and
				various examples.</p>

				<p><b>Final Deliverables -</b></p>

				<ul>
				<li>A loadable kernel module - <a
				href="https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/sys/security/mac_ipacl">mac_ipacl
				in sys/security/mac_ipacl</a></li>
				<li>ATF tests for the module in <a
				href="https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/tests/sys/mac/ipacl">tests/sys/mac/ipacl</a></li>
				<li>A man page for this new mac module - mac_ipacl.4 in
				<a
				href="https://github.com/shivankgarg98/freebsd/blob/shivank_MACPolicyIPAddressJail/share/man/man4/mac_ipacl.4">share/man/man4/mac_ipacl.4</a></li>
				</ul>

				<p>This is a new project, developed as part of <b>Google
				Summer of Code'19</b>
				under the guidance of <b>Bjoern A. Zeeb</b>
				<<a href="mailto:bz@FreeBSD.org">bz@FreeBSD.org</a>>. The module is
				<b>reviewed</b> and <b>Revision for this project
				is accepted and ready to
				land</b>. It is yet to be merged with FreeBSD HEAD, and
				waiting to be tested
				by few more hands in the industry.</p>

				<p>I'll be very thankful if you can give this module a try
				and share your
				valuable experience about it. Please be free to share your
				ideas and
				feedback on this module and please do not hesitate to send
				me an email.</p>

				</body>

				</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
				allanjudeUnsubmitted Done Inline Actions A man page for this ... allanjude: A man page for this ...
				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__&known_name=fusefs&list_id=289348&query_based_on=fusefs&query_format=advanced&short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&short_desc_type=anywordssubstr">buggy</a>
				and out-of-date. Our implementation is about 11 years
				behind.</p>

				<p>I completed this work during Q3. I fixed a few
				newly-introduced bugs, fixed a
				long-standing sendfile bug that affects FUSE

				([236466](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236466))
				and merged
				everything to head and stable/12. Then I fixed the
				resulting Coverity CIDs.
				There have been no new FUSE-related bug reports, so I can
				only assume that
				everything is working great. Report any problems to
				asomers@FreeBSD.org.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='proj'>
				<title>NFS Version 4.2 implementation</title>

				<contact>
				<person>
				<name>Rick Macklem</name>
				<email>rmacklem@freebsd.org</email>
				</person>
				</contact>

				<body>
				<p>RFC-7862 describes a new minor revision to the NFS Version
				4 protocol.
				This project implements this new minor revision.</p>

				<p>The NFS Version 4 Minor Version 2 protocol adds several
				optional
				features to NFS, such as support for SEEK_DATA/SEEK_HOLE,
				file
				copying done on the server that avoids data transfer over
				the wire
				and support for posix_fallocate(), posix_fadvise().
				Hopefully these features can improve performance for
				certain applications.</p>

				<p>The implementation is now nearing completion and recent
				work has been
				mostly testing. A cycle of interoperability testing with
				Linux has
				just been completed. The main area that still needs
				testing is use
				of the pNFS server with NFSv4.2 and that should start
				soon.
				Once testing of pNFS is completed, I believe the code is
				ready to
				be incorporated into FreeBSD head/current.</p>

				<p>Testing by others would be appreciated. The modified
				kernel can be
				found at https://svn.freebsd.org/base/projects/nfsv42/sys
				and should
				run with a recent FreeBSD head/current system. Client
				mounts need the
				"minorversion=2" mount option to enable this protocol.</p>

				</body>

				</project>

				<project cat='proj'>
				<title>FAT / msdosfs support for makefs(8)</title>

				<contact>
				<person>
				<name>Ed Maste</name>
				<email>emaste@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>In order to streamline the process of creating install or
				virtual
				machine system images we needed FAT filesystem support in
				allanjudeUnsubmitted Done Inline Actions missing space in minor version allanjude: missing space in minor version
				makefs(8).
				Makefs was originally developed in NetBSD, and FAT support
				was added
				there not much later, but after the tool was ported to
				FreeBSD.</p>

				<p>Siva Mahadevan, one of the FreeBSD Foundation's interns
				from the
				University of Waterloo, worked on porting FAT support from
				NetBSD.
				I <a href="https://reviews.freebsd.org/D16438">rebased and
				updated</a> Siva's
				work, and <a
				href="https://reviews.freebsd.org/rS351273">committed</a>
				it during
				this quarter. After a few follow-up fixes we are able to
				build FAT
				filesystem images without using md(4) and without
				requiring root.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='proj'>
				<title>syzkaller on FreeBSD</title>

				<contact>
				<person>
				<name>Andrew Turner</name>
				<email>andrew@FreeBSD.org</email>
				</person>
				<person>
				<name>Mark Johnston</name>
				<email>markj@FreeBSD.org</email>
				</person>
				<person>
				<name>Michael Tuexen</name>
				<email>tuexen@FreeBSD.org</email>
				</person>
				<person>
				<name>Samy Al Bahra</name>
				<email>sbahra@freebsd.org</email>
				</person>
				</contact>

				<body>
				<p>See the syzkaller entry in the 2019q1 quarterly report for
				an
				introduction to syzkaller.</p>

				<p>Work has continued on fixing bugs uncovered by syzkaller.
				Over a dozen
				kernel bugs fixed in the past three months have been
				directly attributed
				to syzkaller, and a number of syzkaller reproducers have
				been
				incorporated into our test suite.</p>

				<p>backtrace.io, via Samy, has graciously provided a large
				server for
				running a dedicated syzkaller instance to fuzz FreeBSD
				under bhyve.
				Though syzbot, the public syzkaller instance run by
				Google, already
				fuzzes FreeBSD, it has proven fruitful to run multiple
				syzkaller
				instances: different instances find different bugs, and
				syzkaller.backtrace.io allows us to experiment with
				FreeBSD-specific
				extensions. In particular, this instance currently uploads
				data about
				each crash to backtrace.io, making it much easier to
				triage and analyze
				crashes. We plan to make this service generally available
				to FreeBSD
				developers in the near future.</p>

				<p>Going forward we will continue to extend syzkaller
				coverage and make it
				simpler for users and developers to run private instances,
				and
				optionally collect kernel crash information for debugging
				or for
				submission.</p>

				</body>

				<sponsor>
				backtrace.io
				</sponsor>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='proj'>
				<title>Rockchip RK3399 SoC's eMMC support</title>

				<contact>
				<person>
				<name>Ganbold Tsagaankhuu</name>
				<email>ganbold@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>The followings features have been added to support RK3399
				SoC eMMC on FreeBSD:</p>

				<ul>
				<li>Extended simple_mfd driver to expose a syscon interface if
				that node is also compatible with syscon. For instance,
				Rockchip RK3399's GRF (General Register Files) is
				compatible
				with simple-mfd as well as syscon and has devices like
				usb2-phy, emmc-phy and pcie-phy etc. under it.</li>

				<li>Made Rockchip's General Register Files driver the subclass
				of Simple MFD driver</li>

				<li>Added driver for Rockchip RK3399 eMMC PHY.</li>

				<li>Added eMMC support codes for Rockchip RK3399 SoC.</li>

				<li>All above was tested on NanoPC-T4 board.</li>
				</ul>

				</body>

				</project>

				<project cat='proj'>
				<title>TPM2 Software Stack (TSS2)</title>

				<contact>
				<person>
				<name>D Scott Phillips</name>
				<email>scottph@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://tpm2-tss.readthedocs.io/en/latest/index.html">tpm2-tss Documentation</url>
				<url href="https://github.com/tpm2-software/">tpm2 Source Repository</url>
				<url href="https://lists.01.org/postorius/lists/tpm2.lists.01.org/">tpm2 mailing list</url>
				<url href="ircs://chat.freenode.net:6697/tpm2.0-tss">tpm2 irc channel</url>
				</links>

				<body>
				<p>Intel has contributed ports of the TPM2 Software Stack to
				the ports tree, with
				the new ports securtity/tpm2-tss, security/tpm2-tools,
				security/tpm2-abrmd.
				<tt>tpm2-tss</tt> contains a set of libraries which expose
				various TPM2 APIs for using
				a TPM conforming to the TCG TPM 2.0 specification.
				<tt>tpm2-tools</tt> provides a set
				of command line tools which use the <tt>tpm2-tss</tt>
				libraries to perform tpm
				operations. Finally, <tt>tpm2-abrmd</tt> is a userspace
				daemon which acts as a TPM
				Access Broker and Resource Manager, multiplexing many TPM
				users onto a single
				TPM device.</p>

				<p>Sponsored by: Intel Corporation</p>

				</body>

				</project>

				<project cat='proj'>
				<title>Improving laptop support</title>

				<contact>
				<person>
				<name>Ed Maste</name>
				<email>emaste@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>The FreeBSD Foundation would like to ensure that running
				FreeBSD on
				contemporary hardware, including laptops, remains viable.
				To that end
				we plan to purchase the latest generation of one or more
				of a family
				of laptops preferred by members of the FreeBSD community,
				evaluate the
				existing state of hardware support, and implement missing
				hardware
				support where possible.</p>

				<p>As the first laptop for this project we have selected a
				7th Generation
				Lenovo X1 Carbon.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='bin'>
				<title>gets(3) retirement</title>

				<contact>
				<person>
				<name>Ed Maste</name>
				<email>emaste@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>gets is an obsolete C library routine for reading a string
				from standard
				input. It was removed from the C standard as of C11
				because there was no
				way to use it safely. Prompted by a comment during Paul
				Vixie's talk at
				vBSDCon 2017 I started investigating what it would take to
				remove gets
				from libc.</p>

				<p><a href="https://reviews.freebsd.org/D12298">The patch</a>
				was posted to Phabricator
				and refined several times, and the portmgr team performed
				several
				<a href="https://bugs.freebsd.org/222796">exp-runs</a> to
				identify ports broken by
				the removal. Symbol versioning is used to preserve binary
				compatibility
				for existing software that uses gets.</p>

				<p>The change was <a
				href="https://reviews.freebsd.org/rS351659">committed</a>
				in
				September, and will be in FreeBSD 13.0.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='kern'>
				<title>Kernel Mapping Protections</title>

				<contact>
				<person>
				<name>Mark Johnston</name>
				<email>markj@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>Modern CPU architectures have the ability to flag memory
				mappings as
				"no-execute" (NX), which prevents that memory from being
				executed by a
				processor. NX mappings are an important security
				mitigation since they help
				segregate code and data, blocking unintentional execution
				of memory whose
				contents is controlled by an attacker. W^X (write XOR
				execute) is a security
				policy which disallows the creation of mappings that are
				simultaneously
				writeable and executable. Under this policy, memory whose
				contents can be
				modified must be mapped with the NX flag. This policy
				makes it harder to exploit
				bugs that permit an attacker to arbitrarily overwrite
				data.</p>

				<p>FreeBSD has long made use of the NX flag for userspace
				mappings whenever
				possible, but only in the past several years has it been
				applied to kernel
				mappings. A recent project has sought to implement a
				W^X-by-default policy for
				the amd64 kernel by completing an audit of the remaining
				executable mappings in
				the kernel, and making modifications to either apply the
				NX bit to those
				mappings or to make them read-only. This work has landed
				in HEAD and will be
				available in FreeBSD 13.0 and 12.2. Similar work for other
				CPU architectures is
				also planned.</p>

				<p>To help audit kernel mapping protections, the
				vm.pmap.kernel_maps sysctl was
				added; it dumps a snapshot of the kernel's page table
				entries and their
				attributes. This way, mappings violating the W^X policy
				can easily be
				discovered and investigated, and the sysctl provides
				information useful to
				anyone interested in kernel memory layout.</p>

				<p>With a few rare exceptions, the only kernel mappings which
				require execute
				permission are those of the kernel executable itself, and
				loadable kernel
				modules. A number of other regions of memory were
				unnecessarily being mapped
				without NX, and these were identified and corrected first.
				To address the
				kernel code mappings, the amd64 kernel linker script was
				modified to pad the
				.text segment to a 2MB boundary. To improve performance,
				the kernel creates
				superpage mappings of its .text segment, but this means
				that any data cohabiting
				the final 2MB .text mapping is mapped with execute
				permissions. The padding
				allows executable code to be segregated from data which
				allanjudeUnsubmitted Done Inline Actions makes it harder allanjude: makes it harder
				follows in the kernel
				image, avoiding this problem and maintaining the superpage
				optimization at the
				expense of some wasted RAM.</p>

				<p>Enforcing W^X turned out to be somewhat trickier. Unlike
				other CPU
				architectures supported by FreeBSD, amd64 kernel modules
				are linked as
				relocatable object files, i.e., .o files. (On other
				architectures, they are
				dynamically shared objects (DSOs, or .so files), as one
				might naively expect.)
				The use of .o files means that amd64 kernel modules
				contain more efficient code
				than they would if linked as DSOs, since DSOs inherently
				make use of certain
				types of indirection which allow shared libraries to be
				loaded at arbitrary
				addresses, and this indirection is useless in the kernel.
				As part of this
				project an attempt was made to switch amd64 to using DSOs
				as well, since the
				cost of this indirection can largely be mitigated with
				modern toolchains, but it
				was found that the use of DSOs would also force a change
				to the code model used
				when compiling amd64 kernel code, resulting in a further
				performance penalty.</p>

				<p>The main obstacle with the use of .o files is that
				sections are not page-aligned
				by default; the segregation of sections with differing
				mapping protection
				requirements is done by the static linker when linking a
				DSO or executable file.
				Since mapping protections are applied at the granularity
				of the page size (4KB
				on amd64), the overlap of sections within a page causes
				problems since, for
				example, the end of the read-only .text section may
				overlap with the beginning
				of the read-write .data section. One possible solution is
				to perform any
				required section reordering and padding at kernel module
				load time, but this
				approach breaks debugging tools such as dtrace(1) and kgdb
				which assume that the
				kernel linker does not modify the layout of loadable
				modules. As a result, an
				amd64 kernel module linker script is now used to insert
				padding for specific
				sections. Finally, the kernel linker was modified to
				restrict mapping
				protections based on section flags.</p>

				<p>As a result of all of this, amd64 kernels now boot without
				any writeable,
				executable mappings. Though some of the work was
				architecture-specific, much of
				it can and will be leveraged to provide the same policy
				for our other supported
				architectures.</p>

				</body>

				<sponsor>
				Netflix
				</sponsor>

				</project>

				<project cat='kern'>
				<title>PROT_MAX mmap/mprotect maximum protections API</title>

				<contact>
				<person>
				<name>Brooks Davis</name>
				<email>brooks@freebsd.org</email>
				</person>
				</contact>

				<links>
				<url href="https://reviews.freebsd.org/rS349240">PROT_MAX commit</url>
				</links>

				<body>
				<p>Unix-like systems provide the <tt>mmap(2)</tt> system call
				to allocate memory or
				map files or devices into memory with specified access
				protection, and the
				<tt>mprotect(2)</tt> system call to change protections on
				mapped memory. Protection
				flags specify whether the memory may be read, written,
				and/or executed
				(<tt>PROT_READ</tt>, <tt>PROT_WRITE</tt>, <tt>PROT_EXEC</tt>
				respectively). Traditionally,
				<tt>mprotect(2)</tt> can be used to set any desired
				protections (except that a
				shared mapping of a file opened read-only cannot have
				<tt>PROT_WRITE</tt> set).</p>

				<p>A new macro <tt>PROT_MAX()</tt> adds a facility for
				specifying the maximum possible
				protection flags for <tt>mmap(2)</tt> and
				<tt>mprotect(2)</tt> calls. The program can then
				specify whether a mapping may be changed in the future to
				allow a given access
				protection. For example, a memory mapping can be set such
				that it can have
				read and write protections set, but may never be made
				executable.</p>

				<p>Maximum protection values are provided to the
				<tt>PROT_MAX()</tt> macro, and are
				OR'd with regular protection values.</p>

				<p>This change allows (e.g.) a region that must be writable
				during run-time
				linking or JIT code generation to be made permanently
				allanjudeUnsubmitted Done Inline Actions I don't think the underscore needs to be escaped here allanjude: I don't think the underscore needs to be escaped here
				read+execute after
				writes are complete. This complements Write-XOR-Execute
				(W^X) protections
				available on other operating systems, allowing more
				precise control by the
				programmer.</p>

				<p>For example, to request memory that cannot be made
				executable:
				<ttt>
				mmap(NULL, size, PROT_READ \| PROT_WRITE \|
				PROT_MAX(PROT_READ \| PROT_WRITE),
				MAP_ANON, -1, 0);
				</ttt></p>

				<p>and to request memory that may have execute permission
				enabled later on, but
				is not currently executable:</p>

				<p><ttt>
				mmap(NULL, size,
				PROT_READ \| PROT_WRITE \| PROT_MAX(PROT_READ \| PROT_WRITE \|
				allanjudeUnsubmitted Done Inline Actions PROT_READ did not get the <tt> markup, but kept the `` markdown markup, likely due to the leading ( allanjude: PROT_READ did not get the <tt> markup, but kept the `` markdown markup, likely due to the…
				PROT_EXECUTE),
				MAP_ANON, -1, 0);
				</ttt></p>

				<p>This change alters mprotect argument checking and returns
				an error when
				unhandled protection flags are set. This differs from
				POSIX (in that POSIX
				only specifies an error if a valid permission can not be
				set), but is the
				documented behavior on Linux and more closely matches
				historical mmap behavior.</p>

				<p>In addition to explicit setting of the maximum
				permissions, an experimental
				sysctl <tt>vm.imply_prot_max</tt> causes mmap to assume
				that the initial permissions
				requested should be the maximum when the sysctl is set to
				1. This behavior is
				known to break code that uses <tt>PROT_NONE</tt>
				reservations before mapping contents
				into part of the reservation. A later version of this work
				is expected to
				provide per-binary and per-process opt-in/out options and
				this sysctl may be
				removed in its current form. As such it is undocumented.</p>

				<p>While these flags are non-portable, they can be used in
				portable code with
				simple ifdefs to expand <tt>PROT_MAX()</tt> to 0.</p>

				<p>Sponsors: DARPA, AFRL</p>

				</body>

				</project>

				<project cat='kern'>
				<title>Kernel ZLIB Update</title>

				<contact>
				<person>
				<name>Xin Li</name>
				<email>delphij@FreeBSD.org</email>
				</person>
				<person>
				<name>Yoshihiro Ota</name>
				<email>ota@j.email.ne.jp</email>
				</person>
				</contact>

				<body>
				<p>The ZLIB is a compression library is widely used in
				various software.
				The FreeBSD system had used an ancient (over 20 year-old)
				version
				of zlib (version 1.0.4) and total of 3 versions, one in
				user-land,
				one in ZFS, and one in kernel.
				Xin and Yoshihiro upgraded zlib to the latest and
				eliminated 2 extra copies.
				Along the efforts, zlib version was upgraded to 1.2.11,
				netgraph's ppp is
				re-implemented to use the standard zlib, and removed
				unmaintained code.
				We now only have one and the latest version of zlib in
				FreeBSD code base,
				new compress, compress2, and uncompress APIs exposed in
				the kernel,
				and importing changes from zlib will be simple.</p>

				<p>Kernel zlib changes</p>

				<ul>
				<li><a href="https://reviews.freebsd.org/D20193">sys/crc32.h
				is split to avoid object file name conflict with
				ZLIB's</a></li>

				<li><a href="https://reviews.freebsd.org/D20191">contrib/zlib
				is moved to sys/contrib/zlib</a></li>

				<li><a href="https://reviews.freebsd.org/D19706">Kernel
				started switching to sys/contrib/zlib and ZFS copy
				dropped</a></li>

				<li><a href="https://reviews.freebsd.org/D21156">Kernel
				zcalloc is introduced and compress, compress2, and
				uncompress APIs are exposed to kernel</a></li>

				<li><a href="https://reviews.freebsd.org/D21375">Removed zlib
				1.0.4 from kernel</a></li>
				</ul>

				<p>
				Kernel zlib user updates</p>

				<ul>
				<li><a href="https://reviews.freebsd.org/D21176">kern_ctf.c
				updated</a></li>

				<li><a
				href="https://reviews.freebsd.org/D20222">opencryptodeflate
				updated</a></li>

				<li><a href="https://reviews.freebsd.org/D20271">geom_uzip
				updated</a></li>

				<li><a
				href="https://reviews.freebsd.org/D21408">subr_compressor
				updated</a></li>

				<li><a href="https://reviews.freebsd.org/D20272">if_mxge
				updated</a></li>

				<li><a href="https://reviews.freebsd.org/D21175">bxe
				updated</a></li>

				<li><a href="https://reviews.freebsd.org/D21186">ng_deflate
				updated</a></li>
				</ul>

				<p>
				Legacy code removals</p>

				<ul>
				<li><a href="https://reviews.freebsd.org/D20190">Removed MIPS
				zlib elf trampoline</a></li>

				<li><a href="https://reviews.freebsd.org/D20248">Removed kgzip
				and kgzldr</a></li>

				<li><a href="https://reviews.freebsd.org/D21099">Removed
				gzip'ed a.out support</a></li>

				<li><a href="https://reviews.freebsd.org/D21072">Removed ArmvX
				elf_trampoline.c</a></li>
				</ul>

				</body>

				</project>

				<project cat='kern'>
				<title>Casueword(9) livelock</title>

				<contact>
				<person>
				<name>Konstantin Belousov</name>
				<email>kib@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>The Compare-And-Swap (CAS) is one of the fundamental
				building blocks
				for hardware-assisted atomic read/modify/write operations.
				Some
				architectures support it directly, for instance x86 and
				sparc. Others
				provide different building blocks, usually the pair of
				Load
				Linked/Store Conditional instructions (ll/sc) which can be
				used to construct
				CAS or other atomic operations like Fetch-And-Add or any
				atomic
				arithmetic ops using plain arithmetic instructions. An
				example is the
				LDXR/STXR pair on AArch64.</p>

				<p>The ll/sc operation is performed by first using the load
				linked
				instruction to load a value from memory and simultaneously
				mark the
				cache line for exclusive access. The value is then updated
				by the
				store conditional instruction, but only if there were not
				any writes to
				the marked cache line. Any write by another CPU makes the
				store
				instruction fail. So typically atomic primitives on ll/sc
				architectures retry the whole operation if only store
				failed, because
				it just means that this CPU either lost a race, or even
				the failure
				was spurious. This is so called strong version of CAS and
				atomics.
				If primitive returns failure instead, the CAS variant is
				called weak
				by C standard.</p>

				<p>For the FreeBSD threading library lock implementation,
				when the fast path
				mode in userspace was not possible, the kernel often needs
				to do a CAS
				operation on user memory location. In addition to all
				guarantees of
				normal CAS, it also must ensure the safety and tolerance
				to paging.
				In FreeBSD, the casueword32(9) primitive provides CAS on
				usermode
				32bit words for kernel. Casueword32(9) was implemented as
				strong CAS,
				similarly to the mode of operation of hardware CAS
				instructions on
				x86.</p>

				<p>Using the strong implementation for casueword may be
				dangerous,
				since the same address is potentially accessible to other,
				potentially
				malicious, threads in the same or other processes. If
				such a thread constantly dirties the cache line used by a
				ll/sc loop, it
				could practically force the kernel-mode thread to remain
				stuck in the loop
				forever. Since the loop is tight, and it does not check
				for signals,
				the thread cannot be stopped or killed.</p>

				<p>The solution is to make the casueword implementation weak,
				which means that
				the interface of the primitive must be changed to allow
				notifying the
				caller about spurious failures. Also, it is now the
				caller's responsibility
				to retry as appropriate.</p>

				<p>The change to casueword was made for all architectures.
				Even on x86,
				the PSL.ZF value after the CMPXCHG instruction was
				returned directly
				for the new casueword. All two dozens uses of the
				primitive, all
				located in <i>kern_umtx.c</i>, were inspected
				and retry added as needed.</p>

				<p>As a somewhat related note, in-kernel
				<tt>atomic_cmpset(9)</tt> operations are
				strong, while <tt>atomic_fcmpset(9)</tt> should be weak,
				unless broken by
				a specific architecture. The general attitude seems to be
				that retry is the
				duty of the primitive's caller.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='kern'>
				<title>Signals delivered on unhandled Page Faults</title>

				<contact>
				<person>
				<name>Konstantin Belousov</name>
				<email>kib@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>By necessity, handling of page faults is separated into
				two pieces. The
				first is the architecture-dependent low-level machine
				exception handler,
				and the second is the architecture-independent
				<tt>vm_fault()</tt> function in
				<i>sys/vm/vm_fault.c</i>.</p>

				<p>Machine-dependent code for page faults typically consists
				of three
				components: a trampoline written in assembly which creates
				the C execution
				environment and gathers hardware-supplied data about page
				fault reason, a
				<tt>trap()</tt> function which is common C-level entry
				point to dispatch all
				exceptions processing, and the <tt>trap_pfault()</tt> C
				function to specifically
				handle page faults. <tt>trap_pfault()</tt> calls
				<tt>vm_fault()</tt> when help from VM is
				needed to resolve the situation.</p>

				<p>If the fault was handled either by
				<tt>trap()</tt>/<tt>trap_pfault()</tt> or
				<tt>vm_fault()</tt>,
				the faulting instruction is restarted. If fault cannot be
				handled for
				any reason, the next action depends on the mode in which
				the fault occured.
				If it was in kernel, and the kernel installed a helper,
				then the helper is
				called instead of returning to the faulting instruction.
				Otherwise,
				a kernel-mode page fault causes a panic.</p>

				<p>If the unhandled fault occured in usermode, then all
				allanjudeUnsubmitted Done Inline Actions This item seems to be a duplicate. It exists at line 1422 allanjude: This item seems to be a duplicate. It exists at line 1422
				Unixes send a
				signal to the thread whose execution caused the exception.
				POSIX (or
				Single Unix Specification) lists several cases where a
				signal should be
				sent, and specifies the signal number and <tt>si_code</tt>
				from siginfo that
				must be supplied with the signal.</p>

				<p>Unfortunately, FreeBSD was rather non-compliant in this
				regard. A long
				time ago, to improve compliance, we changed the signal
				sent on access
				to a page with permissions incompatible with the access
				mode.
				That caused multiple problems with garbage collection
				(GC)-based runtimes
				which incorporated knowledge of the FreeBSD quirks, so the
				<tt>machdep.prot_fault_translation</tt> sysctl knob was
				added. More cases of
				incompatibility were identified recently.</p>

				<p>Part of the problem is that code to calculate the signal
				and <tt>si_code</tt> from
				the Mach error returned by <tt>vm_fault()</tt> was located
				in <tt>trap_pfault()</tt>. In
				other words, each architecture did that on its own, with a
				specific set
				of bugs and non-compliance. Sometimes code even
				mis-interpreted returned
				Mach errors as <tt>errno</tt>.</p>

				<p>A new helper function <tt>vm_fault_trap()</tt> was added,
				that does several
				things for trap handlers: it creates ktrace points for
				faults, calls
				<tt>vm_fault()</tt>, and then interprets the result in
				terms of the user-visible
				error condition, returning precalculated signal number and
				<tt>si_code</tt> to
				the caller. Now <tt>trap_pfault()</tt> only needs to
				provide signal numbers
				for truly machine-dependent errors. For amd64, an example
				of such a
				case is a protection key violation.</p>

				<p>Besides compliance and bug fixes, we also provided some
				refinements to
				userspace about the reason of the delivered signal. For
				instance, on
				SIGBUS caused by copy-on-write failure due to exceeding
				swap
				reservation limit, we provide specific <tt>si_code</tt>
				<tt>BUS_OOMERR</tt>.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>
				allanjudeUnsubmitted Done Inline Actions we don't need to escape _. This likely needs to be checked throughout the entire file allanjude: we don't need to escape _. This likely needs to be checked throughout the entire file

				<project cat='kern'>
				<title>Randomized Top of Stack pointer</title>

				<contact>
				<person>
				<name>Konstantin Belousov</name>
				<email>kib@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>After the ASLR so useful addition, next in the series of
				the
				buzzword-compliant checkboxes is the stack addresses
				randomization.</p>

				<p>The main userspace thread stack on FreeBSD is
				traditionally allocated
				allanjudeUnsubmitted Done Inline Actions trap_pfault() did not get the <tt> markup allanjude: trap_pfault() did not get the <tt> markup
				from the top of the user address space and grows down.
				Besides the
				initial pointer for the stack on userspace entry, this
				area also
				contains structures for program arguments and environment
				(so called
				strings), and aux vector data for ELF images.</p>

				<p>Considering the goal of randomizing the addresses of
				strings and main
				thread initial frame, moving the main stack area in the
				address space
				is not feasible. It would cause significant ABI breakage,
				invalidates
				the knowledge already coded into many introspection tools,
				and causes
				unneeded additional fragmentation of the user address
				space.</p>

				<p>Instead a typical approach of adding a gap of randomized
				size between
				top of stack and a place for strings was used. It is done
				in a way
				which preserves the stack alignment requirement. Stack gap
				is only
				enabled if ASLR is enabled (not default) and stack gap
				itself is
				enabled (default if ASLR is enabled). Stack gap is
				specified in
				percentage of the total stack size that can be used for
				maximum gap.</p>

				<p>The main drawback of the gap approach was shortly
				identified. Since
				gap is cut from the normal stack area, attempts of the
				programs to
				reduce stack size using rlimit(RLIMIT_STACK) could cut the
				active stack
				region if new limit happens to be smaller than the gap.
				E.g. on amd64
				with its default 512M main thread stack, even one percent
				of the max
				gap gives approximately 5M of unused stack, that can blow
				up the limit
				of several KBs.</p>

				<p>Typical reason for using rlimit(2) this way is for
				programs that wire
				all of its address space with mlockall(2), trying to
				reduce potential
				wired stack size to avoid exceeding RLIMIT_MEMLOCK.</p>

				<p>First victim of that issue was ntpd, which resets the
				stack limit
				after start for a really small value. Currently the wiring
				was removed
				from ntpd, because apparently it does not make the
				timekeeping better
				by any means, contrary to popular belief.</p>

				<p>My opinion is that the problem is more in the user
				interface area than
				in the gap approach itself. We should make it easy to
				specify small
				gap sizes, which cannot be done with integral percentage
				interface.
				So far I did not formulated a way to do this which I would
				like, and
				since nobody looked for a good solution because after ntpd
				was fixed,
				the severity of the issue seems very low.</p>

				</body>

				<sponsor>
				The FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='arch'>
				<title>Broadcom ARM64 SoC support</title>

				<contact>
				<person>
				<name>Michal Stanek</name>
				<email>mst@semihalf.com</email>
				</person>
				<person>
				<name>Kornel Duleba</name>
				<email>mindal@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):
				fixes and improvements,</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 Q4 of 2019.</li>
				</ul>

				</body>

				<sponsor>
				Juniper Networks, Inc
				</sponsor>

				</project>

				<project cat='arch'>
				<title>FreeBSD/powerpc Project</title>

				<contact>
				<person>
				<name>Mark Linimon (ports)</name>
				<email>linimon@FreeBSD.org</email>
				</person>
				<person>
				<name>Justin Hibbits (src)</name>
				<email>jhibbits@FreeBSD.org</email>
				</person>
				<person>
				<name>Piotr Kubaj (ports)</name>
				<email>pkubaj@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://wiki.freebsd.org/powerpc/ports">Status of FreeBSD ports on PowerPC</url>
				<url href="https://wiki.freebsd.org/powerpc/ports/PortsOnGcc">Status of FreeBSD ports on PowerPC built using gcc</url>
				<url href="https://wiki.freebsd.org/powerpc/ports/PortsOnClang">Status of FreeBSD ports on PowerPC built using clang</url>
				<url href="https://wiki.freebsd.org/powerpc/llvm-elfv2">Bringing LLVM to PowerPC64 target, using OpenPower ELF v2 ABI</url>
				</links>

				<body>
				<p>The FreeBSD/powerpc project continues to make great
				strides. However,
				as we discovered at BSDCan 2019, we have not done a great
				job of letting
				people know.</p>

				<p>Key points:</p>

				<ul>
				<li>powerpc64 src on recent hardware has been
				production-quality for over
				a year now.</li>
				<li>powerpc64 ports has been developer-quality for over 18
				months now.</li>
				</ul>

				<p>
				The main targeted platforms:</p>

				<ul>
				<li>powerpc64 on IBM POWER8 and POWER9 chips (the most recent
				available).
				This is the primary focus going forward. FreeBSD 12 is
				required;
				FreeBSD 13 is recommended.</li>
				<li>powerpc64 on older Apple Power Macs, on a continuing but
				secondary
				basis. Any FreeBSD version should work.</li>
				<li>powerpc64 on x5000. However, this is still developer-only
				quality.
				FreeBSD 13 is recommended.</li>
				<li>powerpcspe on Amiga A1222. However, this is still
				developer-only quality.
				FreeBSD 13 is recommended.</li>
				</ul>

				<p>
				The software status:</p>

				<ul>
				<li>powerpc*/12 and earlier still remain on the antiquated
				gcc4.2.1 in
				base.</li>
				<li>powerpc*/13 will soon be switched to llvm90 in base. A
				great deal
				of work has been undertaken to ensure as few regressions
				as possible.
				Once that switch has occurred (see llvm-elfv2 link above),
				powerpc*/13
				support on gcc4.2.1 will no longer be a priority.</li>
				<li>FreeBSD.org package sets are available for powerpc64/12
				(quarterly)
				and powerpc64/13 (default) through the usual method.</li>
				<li>Firefox works on powerpc64 using experimental (not-yet
				committed) patches,</li>
				<li>As of the most recent package build on powerpc64/13 (still
				gcc4.2.1),
				the following statistics apply:
				<table class="tblbasic">
				<tr><th> Queued </th><th> Built </th><th> Failed </th><th> Skipped </th><th> Ignored </th></tr>
				<tr><td> 33306 </td><td> 30514 </td><td> 245 </td><td> 1686 </td><td> 861 </td></tr>
				</table>
				</li>
				<li>More ports fixes are being committed every day.</li>
				</ul>

				<p>
				Also, Piotr would like to thank the FreeBSD Foundation for
				funding
				his personal Talos, and Raptor (via its IntegriCloud
				subsidiary) for
				loaning a server on which talos.anongoth.pl runs.</p>

				<p>The team would like to thank IBM for the loan of two
				POWER8 machines,
				and Oregon State University (OSU) for providing the
				hosting. As well,
				we would like to thank the clusteradm team for keeping the
				Tyan POWER8
				machines online that are hosted at <a
				href="https://www.nyi.net">NYI</a>.</p>

				</body>

				</project>

				<project cat='arch'>
				<title>NXP ARM64 SoC support</title>

				<contact>
				<person>
				<name>Marcin Wojtas</name>
				<email>mw@semihalf.com</email>
				</person>
				<person>
				<name>Artur Rojek</name>
				<email>ar@semihalf.com</email>
				</person>
				</contact>

				<body>
				<p>The Semihalf team initiated working on FreeBSD support for
				the
				<a
				href="https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/qoriq-layerscape-arm-processors/qoriq-layerscape-1046a-and-1026a-multicore-communications-processors:LS1046A">NXP
				LS1046A SoC</a></p>

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

				<p>Completed since the last update:</p>

				<ul>
				<li>DPAA Network interface support</li>

				<li>SD/MMC</li>

				<li>USB3.0</li>

				<li>I2C</li>

				<li>GPIO</li>
				</ul>

				<p>
				In progress:</p>

				<ul>
				<li>QSPI</li>

				<li>Network performance improvements</li>
				</ul>

				<p>
				Todo:</p>

				<ul>
				<li>Upstreaming of developed features. This work is expected
				to
				be submitted/merged to HEAD in the Q4 of 2019.</li>
				</ul>

				<p></p>

				</body>

				<sponsor>
				Alstom Group
				</sponsor>

				</project>

				<project cat='arch'>
				<title>FreeBSD support for the forthcoming Arm Morello CPU, SoC, and board</title>

				<contact>
				<person>
				<name>Robert Watson</name>
				<email>rwatson@FreeBSD.org</email>
				</person>
				<person>
				<name>Andrew Turner</name>
				<email>andrew@FreeBSD.org</email>
				</person>
				<person>
				<name>Brooks Davis</name>
				<email>brooks@FreeBSD.org</email>
				</person>
				</contact>

				<body>
				<p>In September 2019, Arm announced Morello, an experimental
				multicore superscalar
				ARMv8-A CPU, SoC, and prototype board extended to
				implement the CHERI
				protection model. Morello will become available in 2021.
				More details can be
				found in
				<a
				href="https://www.arm.com/blogs/blueprint/digital-security-by-design">Arm's
				blog</a>, a
				<a
				href="https://www.lightbluetouchpaper.org/2019/10/18/ukri-digital-security-by-design-a-190m-research-programme-around-arms-morello-an-experimental-armv8-a-cpu-soc-and-board-with-cheri-support/">Light
				Blue Touchpaper blog</a>,
				and the main
				<a
				href="https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/">CHERI
				website</a>.</p>

				<p>We have updated CheriBSD, a CHERI-adapted version of
				FreeBSD originally
				targeted at the MIPS-based SRI/Cambridge CHERI processor
				prototype, to support
				the current draft architecture. This includes full
				userspace spatial and
				referential memory safety

				<a href="https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf">CheriABI</a>,
				as well as backwards compatibility to support running
				existing ARMv8-A
				userspace binaries.</p>

				<p>We will continue to update CheriBSD/Morello as the ISA is
				finalised. Will also
				closely track the public CheriBSD/MIPS trunk, picking up
				new software features
				utilizing CHERI as they mature, as well as to pick up
				changes from the baseline
				FreeBSD development trunk.</p>

				<p>We currently anticipate releasing CheriBSD/Morello as open
				source once the ISA
				and toolchain are published in 2020.</p>

				<p>Sponsors: DARPA, AFRL</p>

				</body>

				</project>

				<project cat='ports'>
				<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</url>
				</links>

				<body>
				<p>The FreeBSD Ports Management Team, tasked with overseeing
				the Ports Tree and
				its committers, reports that the following events happened
				during 2019Q3:</p>

				<p>The number of ports grew to just under 38,000 during the
				last quarter. We have
				just over 2,000 open ports PRs, of which 400 are
				unassigned. In this period,
				169 committers made 7,340 commits to HEAD and 561 commits
				to the quarterly
				branch. This shows that the trend of last quarter of
				increased activity is
				continuing.</p>

				<p>During the last quarter, we welcomed Santhosh Raju (fox@)
				and Dmitri Goutnik
				(dmgk@) to the team, and said goodbye to gabor@. During
				the last quarter,
				feld@ decided to step down from the portmgr@ and
				ports-secteam@ teams. We
				would like to thank them for their past services.</p>

				<p>In the last three months, bapt@ put on his engineering hat
				and released a new
				version of pkg (1.12), added support for overlays to the
				Ports Tree, fixed
				two Make targets (deinstall-depends and reinstall), and
				cleaned up
				bsd.sites.mk.</p>

				<p>On the infrastructure side, USES=pure became obsolete and
				has therefore been
				removed, and two new USES, xorg and xorg-cat have been
				added and replace the
				old bsd.xorg.mk. Two new keywords, ldconfig and
				ldconfig-linux, were added to
				simplify formatting of package lists.</p>

				<p>A number of default versions changed: Lazarus to 2.0.4,
				Linux to CentOS 7,
				LLVM to 9.0, Perl to 5.30, PostgreSQL to 11, and Ruby to
				2.6. Of the big
				user-visible ports, Firefox got updated to 69.0.1,
				Firefox-esr to 68.1.0,
				Chromium to 76.0.3809.132, and Xfce to 4.14.</p>

				<p>During the last quarter, antoine@ ran 48 exp-runs to test
				package updates, test
				updating bsd.java.mk, test the new ldconfig and
				ldconfig-linux keywords, test
				default version updates, test the new xorg and xorg-cat
				USES, test base
				updates, and test various improvements to Go and Ruby.</p>

				</body>

				</project>

				<project cat='ports'>
				<title>FreshPorts</title>

				<contact>
				<person>
				<name>Dan Langille</name>
				<email>dvl@FreeBSD.org</email>
				</person>
				</contact>
				allanjudeUnsubmitted Done Inline Actions this markdown did not get turned into a link properly allanjude: this markdown did not get turned into a link properly

				<links>
				<url href="https://www.FreshPorts.org/">FreshPorts</url>
				<url href="https://github.com/FreshPorts/git_proc_commit">git_proc_commit code</url>
				<url href="https://news.freshports.org/2019/09/03/things-you-didnt-know-freshports-can-do/">Things you didn’t know FreshPorts can do</url>
				</links>

				<body>
				<p>FreshPorts consolidates commits into an easy-to-follow
				format so you can track changes to your favorite ports.
				It also processes src, doc, and www commit. FreshPorts
				parses
				incoming emails and refreshes the database with what it
				finds.</p>

				<p>In early September I started looking at how FreshPorts
				could use a git repository for processing commits. The
				result was <a
				href="https://news.freshports.org/2019/09/02/git-and-freshports/">an
				approach</a> for identifying new commits and
				for iterating through them.</p>

				<p>The next idea was <a
				href="https://news.freshports.org/2019/09/18/moving-towards-commit-hooks/">commit
				hooks</a> but the most interesting
				bit of that exercise was commit iteration.</p>

				<p>At the EuroBSDCon 2019 FreeBSD Developer summit, I wrote
				up a small requirements section and then received great
				help from two sources:</p>

				<ul>
				<li>Jan-Piet MENS recommended a <a
				href="https://www.freshports.org/devel/py-gitpython/">Python
				library</a> and
				it turned out to be great</li>
				<li>Sergey Kozlov wrote Python code to create xml using
				that Python library</li>
				</ul>

				<p>
				On the trip home, I was able to get the code to parse
				a git commit into XML and loaded into a FreshPorts
				database.</p>

				<p>Returning home from the conference, I created a new
				FreshPorts instance for processing git based on the above.
				The website has needed no changes related to git.</p>

				<p>The remaining tasks:</p>

				<ul>
				<li>automate the script (git pull, etc)</li>

				<li>detect new commits (for later iteration)</li>

				<li>design a light-weight git hook</li>
				</ul>

				<p>
				Event: EuroBSDCon 2019 Hackathon
				Sponsored by: Intel Corporation (work done by Sergey
				Kozlov)</p>

				</body>

				</project>

				<project cat='ports'>
				<title>KDE on FreeBSD</title>

				<contact>
				<person>
				<name>Adriaan de Groot</name>
				<email>kde@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://freebsd.kde.org/">KDE FreeBSD</url>
				<url href="https://community.kde.org/FreeBSD">KDE Community FreeBSD</url>
				</links>

				<body>
				<p>The <i>KDE on FreeBSD</i> project packages the
				software produced by
				the KDE Community for FreeBSD. The software includes a
				full desktop environment, the art application
				<a href="https://kdenlive.org">https://kdenlive.org</a>
				and hundreds of other applications that can be used on
				any FreeBSD desktop machine.</p>

				<p>Along with KDE itself, the team maintains the Qt
				libraries, the CMake
				build system, and a handful of other C++ libraries used in
				the KDE stack.</p>

				<p>The upstream releases KDE Frameworks (libraries) on a
				monthly
				cycle, KDE Plasma (the desktop environment) quarterly and
				a collection of KDE Applications (usable everywhere) twice
				a year.
				The KDE on FreeBSD team chased a dozen updates to these
				components
				so that FreeBSD remains one of the most up-to-date systems
				with KDE software (and Qt).</p>

				<p>A large (and possibly breaking, still needs more
				investigation)
				change came with the release to KDE's Digikam 6.3.0, which
				stopped
				using its previous plugins system (the "old" plugins are
				still used
				by other KDE software).</p>

				<p>A new entry in the net-im category was added for Ruqola, a
				Rocket.chat client for rich instant-messaging.</p>

				<p>CMake was updated twice. This forces the rebuild of
				several thousand
				C++-based ports. The KDE on FreeBSD team then fixes those
				ports,
				regardless of whether the error is in the CMake update, or
				in
				the upstream code. These updates tend to take a large
				amount of effort,
				since they touch unfamiliar (and often very-very-legacy)
				code.</p>

				<p>The <a
				href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=New&bug_status=Open&bug_status=In%20Progress&bug_status=UNCONFIRMED&email1=kde%40FreeBSD.org&emailassigned_to1=1&emailtype1=substring&f0=OP&f1=OP&f2=product&f3=component&f4=alias&f5=short_desc&f7=CP&f8=CP&f9=assigned_to&j1=OR&j_top=OR&o2=substring&o3=substring&o4=substring&o5=substring&o9=substring&query_format=advanced&v2=kde%40&v3=kde%40&v4=kde%40&v5=kde%40&v9=kde%40&human=1">open
				bugs list</a>
				grew to 24 this quarter.
				It tends to hover around 20 items as new things come in
				and old ones are resolved. We welcome detailed bug reports
				and patches. KDE packaging updates are prepared in
				a <a
				href="https://github.com/freebsd/freebsd-ports-kde/">copy
				of the ports repository</a>
				on GitHub and then merged in SVN. We welcome pull requests
				there as well.</p>

				</body>

				</project>

				<project cat='ports'>
				<title>Java on FreeBSD</title>

				<contact>
				<person>
				<name>Greg Lewis</name>
				<email>glewis@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://github.com/freebsd/openjdk-jdk11u">OpenJDK 11 repository at FreeBSD GitHub</url>
				</links>

				<body>
				<p>Over the last few quarters there has been considerable
				work in improving
				support for Java 11 and higher, with some work being
				backported to Java 8.</p>

				<p>Starting with the initial release in March on amd64, over
				the
				intervening months FreeBSD support was added for features
				such as:</p>

				<ul>
				<li>Java Flight Recorder</li>

				<li>HotSpot Serviceability Agent</li>

				<li>HotSpot Debugger</li>

				<li>DTrace</li>

				<li>Javac Server</li>

				<li>Java Sound</li>

				<li>SCTP</li>
				</ul>

				<p>
				In addition, support for the aarch64, i386 and powerpc64
				architectures
				was also added.</p>

				<p>With most features supported, attention turned to
				compliance, using the
				internal JDK test suite as a method of measuring this.
				Most work during
				the third quarter has focused on this, with test failures
				dropping from
				50+ failures to only 2 tier1 test failures (which don't
				appear to impact
				functionality at all). Some significant fixes include:</p>

				<ul>
				<li>A stack overflow crash</li>

				<li>Errors in external process handling</li>

				<li>The unpack200 utility (on little endian systems)</li>

				<li>HotSpot Debugger functionality such as thread enumeration</li>

				<li>Networking functionality</li>
				</ul>

				<p>
				Finally, this work has been forward ported to Java 12 and
				13, with FreeBSD
				gaining support for these versions on or just after the
				day of release.</p>

				<p>Note that this work has been a collaboration with many
				others. While there
				are too many contributors to list here (please take a look
				at the commit
				history of the GitHub repository), I'd like to recognise
				Kurt Miller of
				OpenBSD for his tireless work as a co-collaborator on Java
				for BSD through
				many years.</p>

				<p>I'm also grateful to the sponsorship of the FreeBSD
				Foundation, which has
				allowed me to focus on this work for Q3.</p>

				</body>

				<sponsor>
				FreeBSD Foundation
				</sponsor>

				</project>

				<project cat='ports'>
				<title>XFCE 4.14 update</title>

				<contact>
				<person>
				<name>Guido Falsi</name>
				<email>xfce@FreeBSD.org</email>
				</person>
				</contact>

				<links>
				<url href="https://xfce.org/about/news/?post=1565568000">XFCE 4.14 announce</url>
				</links>

				<body>
				<p>On September 19th the XFCE desktop environment ports have
				been updated
				to the recently released XFCE 4.14 version.</p>

				<p>These updates include upgrades of all the main XFCE
				components to the
				latest versions which have been migrated to GTK3, with few
				exceptions.
				Base components still require and link to GTK2 in addition
				to GTK3 to
				allow older GTK2 XFCE applications, for example panel
				plugins, to keep
				working.</p>

				<p>Due to this change the gtk-xfce-engine theme is deprecated
				since it only
				supports GTK2. The XFCE metaport by default installs the
				greybird theme,
				but it is not enabled by default.</p>

				<p>This new version also includes now it's own
				xfce4-screensaver program
				which is installed by default.</p>

				<p>Finally the default Display Manager on which XFCE depends
				has been
				changed to LightDM.</p>

				<p>Some regressions were reported in bugzilla. In particular
				the one
				affecting most users is a regression in the window
				manager: on specific
				graphic display hardware the window manager fails to
				properly draw
				window decorations, which appear black and blocky on
				affected systems.</p>

				<p>This problem has also been reported in the upstream bug
				tracker and a
				solution is being sought.</p>

				<p>If anyone is experiencing this display glitch and is able
				to test,
				please contact xfce@freebsd.org to help trying to figure
				out a solution.</p>

				</body>

				</project>

				<project cat='third'>
				<title>ClonOS: virtualization platform on top of FreeBSD Operating System</title>

				<contact>
				<person>
				<name>Oleg Ginzburg</name>
				<email>olevole@olevole.ru</email>
				</person>
				</contact>

				<links>
				<url href="https://clonos.tekroutine.com/download.html">ClonOS 19.09</url>
				<url href="https://www.bsdstore.ru/">CBSD</url>
				</links>

				<body>
				<h3>What is ClonOS?</h3>

				<p>ClonOS is a turnkey open-source platform based on FreeBSD
				and the CBSD
				framework. ClonOS offers a complete web UI for an easy
				control, deployment
				and management of FreeBSD jails containers and bhyve/Xen
				hypervisor virtual
				environments.</p>

				<p>ClonOS is currently the only available platforms which
				allow both Xen and bhyve
				hypervisors to coexist on the same host. Since ClonOS is a
				FreeBSD-based
				platform, it has the ability to create and manage jails
				natively, allowing
				you to run FreeBSD applications without losing
				performance.</p>

				<h3>ClonOS/CBSD 2019Q3 Status Report</h3>

				<ul>
				<li>Added support for cloud-init (Linux/BSD VMs) and
				cloudbase-init
				(Windows VMs). It gives the ability to use FreeBSD as IaaS
				platform
				for instant deployment and usage of virtual machines based
				on bhyve
				hypervisor.</li>

				<li>Project started to use own cloud images for better
				stability and
				resiliency.</li>

				<li>New mirrors in France, US and Canada were added for
				distributing ISO/cloud-init images in addition to Russia,
				Latvia and
				Ukraine.</li>

				<li>Now we're using Jenkins CI for testing regular ClonOS
				builds:
				<a
				href="https://jenkins.ircdriven.net/job/Update%20clonos%20packages./">Update
				clonos packages</a> (Thanks to Daniel Shafer)</li>

				<li>New pkg repository was deployed to support ClonOS
				installation
				from packages (at this moment only FreeBSD-12 packages are
				available)
				<a
				href="https://pkg.ircdriven.net/packages/12amd64-clonos/">ClonOS
				package repo</a> (Thanks to Daniel Shafer)</li></ul>

				<p>
				Open issues and tasks:</p>

				<ul>
				<li>Volunteers, contributors and testers are urgently needed
				to
				distribute ClonOS on FreeBSD environments.</li>

				<li>We'd like to expand our mirrors number geographically,
				your help and contribution will be much appriciated.</li>

				<li>We're urgently looking for hosting sponsorship for various
				developing and testing activities.</li></ul>

				</body>

				</project>

				<project cat='third'>
				<title>sysctlinfo</title>

				<contact>
				<person>
				<name>Alfonso Sabato Siciliano</name>
				<email>alfonso.siciliano@email.com</email>
				</person>
				</contact>

				<links>
				<url href="https://gitlab.com/alfix/sysctlinfo">gitlab.com/alfix/sysctlinfo</url>
				</links>

				<body>
				<p>The FreeBSD kernel maintains a Management Information Base
				(MIB) where a
				component (object) represents a parameter of the system.
				The <i>sysctl</i> system
				call explores the MIB to find an object by its Object
				Identifier (OID) and
				calls its handler to get or set the value of the
				parameter. It is often
				necessary to find an object not to call its handler but to
				get its info
				(description, type, name, next object, etc.), so the
				kernel provides an
				undocumented interface implemented in kern_sysctl.c.</p>

				<p>sysctlinfo is a new interface to explore the sysctl MIB
				and to pass the info
				of an object to the userland. The project provides: a
				README, a manual, helper
				macros, examples, tests and converted tools.</p>

				<p>Primarily sysctlinfo provides a new set of sysctl nodes
				(corresponding to the
				kernel interface) to handle an object up to CTL_MAXNAME
				levels:
				sysctl.entryfakename, sysctl.entrydesc, sysctl.entrylabel,
				sysctl.entrykind,
				sysctl.entryfmt and sysctl.entrynextleaf. Moreover new
				features have been
				implemented: the support for the capability mode,
				sysctl.entryname,
				sysctl.entryidbyname and sysctl.entrynextnode. To get all
				the info about an
				object the kernel needs to find it many times, then the
				new
				sysctl.entryallinfo* nodes were written, they are 30%
				more efficient. Finally,
				*byname nodes were added: they search the object by its
				name avoiding to call
				sysctl.name2oid (or similar) to explore the MIB just to
				find the corresponding
				OID.</p>

				<p>sysctlinfo can be installed via <i>sysutils/sysctlinfo-kmod</i>
				or by applying the
				<i>sysctlinfo.diff</i> patch (more efficient than the module
				because uses a shared
				lock). The interface is used by <i>deskutils/sysctlview
				1.5</i>,
				<i>sysutils/nsysctl 1.2</i> and the converted version of
				sysctl(8), sysctlbyname(3),
				sysctlnametomib(3), they should be used to get the value
				of an object with 23/24
				levels or if some level-name has only the '\0' character.
				In the future a new
				<i>byname</i> node will be added to allow sysctlbyname() to
				manage a CTLTYPE_NODE with
				a no-NULL handler, example
				sysctlbyname("kern.proc.pid.\<pid\>").</p>

				</body>

				</project>

				<project cat='third'>
				<title>Nomad pot driver - Orchestrating jails via nomad</title>

				<contact>
				<person>
				<name>Luca Pizzamiglio</name>
				<email>pizzamig@FreeBSD.org</email>
				</person>
				<person>
				<name>Esteban Barrios</name>
				<email>esteban.barrios@trivago.com</email>
				</person>
				</contact>

				<links>
				<url href="https://github.com/trivago/nomad-pot-driver">Nomad pot driver</url>
				<url href="https://github.com/pizzamig/pot">Pot project</url>
				</links>

				<body>
				<p>An experimental project has started to provide jail
				orchestration
				based on <tt>nomad</tt> and the jail framework
				<tt>pot</tt>, similarly to how
				orchestration works with docker.</p>

				<p>This model allows us to split the jail creation and the
				jail deployment.
				Jail images can be created and exported using the
				<tt>pot</tt> framework.
				The images can be deployed and orchestrated using
				<tt>nomad</tt>.
				A driver has been developed to allow <tt>nomad</tt> to
				interact with <tt>pot</tt>.</p>

				<p>One of the goals of this project is to use non-persistent
				jails as
				containers, allowing us to:</p>

				<ul>
				<li>define containers similar to Docker (but not identical,
				because
				the underlaying OS is different)</li>

				<li>identify potential missing features in FreeBSD to support
				such a computational model</li>
				</ul>

				<p>
				In the next quarter, we will launch the first service
				based on this
				project.</p>

				<p>Next steps are:</p>

				<ul>
				<li>provide more guides and howtos</li>

				<li>improve stability, extending the tests suite</li>

				<li>improving tooling to create/manage images</li>
				</ul>

				<p></p>

				</body>

				<sponsor>
				trivago N.V.
				</sponsor>

				</project>

				<project cat='third'>
				<title>ENA FreeBSD Driver Update</title>

				<contact>
				<person>
				<name>Michal Krawczyk</name>
				<email>mk@semihalf.com</email>
				</person>
				<person>
				<name>Maciej Bielski</name>
				<email>mba@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
				allanjudeUnsubmitted Done Inline Actions more escaped underscores allanjude: more escaped underscores
				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>

				allanjudeUnsubmitted Done Inline Actions escaped asterisk allanjude: escaped asterisk
				<p>Completed since the last update:</p>

				<ul>
				<li>Verification and review of the NETMAP support</li>

				<li>Mapping of the memory as WC on A1 instances in order to
				enable LLQ mode</li>
				</ul>

				<p>
				Todo:</p>

				<ul>
				<li>Upstream of NETMAP support</li>

				<li>Upstream of the fix for LLQ mode on A1 instances</li>
				</ul>

				<p></p>

				<sponsor>
				Amazon.com Inc
				</sponsor>

				</body>

				</project>

				</report>