Index: en_US.ISO8859-1/htdocs/news/status/Makefile
===================================================================
--- en_US.ISO8859-1/htdocs/news/status/Makefile
+++ en_US.ISO8859-1/htdocs/news/status/Makefile
@@ -80,6 +80,7 @@
 XMLDOCS+=	report-2017-04-2017-06
 XMLDOCS+=	report-2017-07-2017-09
 XMLDOCS+=	report-2017-10-2017-12
+XMLDOCS+=	report-2018-01-2018-09
 
 XSLT.DEFAULT=	report.xsl
 
Index: en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml
===================================================================
--- /dev/null
+++ en_US.ISO8859-1/htdocs/news/status/report-2018-01-2018-09.xml
@@ -0,0 +1,3374 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
+  Status Report//EN"
+  "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
+
+<!-- $FreeBSD: head/en_US.ISO8859-1/htdocs/news/status/report-template.xml 51132 2017-10-19 01:38:11Z bjk $ -->
+<!-- This file was generated with https://github.com/trasz/md2docbook -->
+<!--
+     Variables to replace:
+     %%START%%     - report month start
+     %%STOP%%      - report month end
+     %%YEAR%%      - report year
+     %%NUM%%       - report issue (first, second, third, fourth)
+     %%STARTNEXT%% - report month start
+     %%STOPNEXT%%  - report month end
+     %%YEARNEXT%%  - next report due year (if different than %%YEAR%%)
+     %%DUENEXT%%   - next report due date (i.e., June 6)
+-->
+
+<report>
+  <date>
+    <month>%%START%%-%%STOP%%</month>
+
+    <year>%%YEAR%%</year>
+  </date>
+
+  <section>
+    <title>Introduction</title>
+
+    <p>With &os; having gone all the way to 12, it is perhaps
+      useful to take a look back at all the things that have been
+      accomplished, in terms of many visible changes, as well as all
+      the things that happen behind the scenes to ensure that &os;
+      continues to offer an alternative in both design,
+      implementation, and execution.</p>
+
+    <p>The things you can look forward to reading about are too
+      numerous to summarize, but cover just about everything from
+      finalizing releases, administrative work, optimizations
+      and depessimizations, features added and fixed, and many areas
+      of improvement that might just surprise you a little.</p>
+
+    <p>Please have a cup of coffee, tea, hot cocoa, or other beverage
+      of choice, and enjoy this culmulative set of reports covering
+      everything that's been done since October, 2017.</p>
+
+    <p>&mdash;Daniel Ebdrup</p>
+  </section>
+
+  <category>
+    <name>team</name>
+
+    <description>&os; Team Reports</description>
+
+    <p>Entries from the various official and semi-official teams,
+      as found in the <a href="&enbase;/administration.html">Administration
+        Page</a>.</p>
+  </category>
+
+  <category>
+    <name>proj</name>
+
+    <description>Projects</description>
+
+    <p>Projects that span multiple categories, from the kernel and userspace
+      to the Ports Collection or external projects.</p>
+  </category>
+
+  <category>
+    <name>arch</name>
+
+    <description>Architectures</description>
+
+    <p>Updating platform-specific features and bringing in support
+      for new hardware platforms.</p>.
+  </category>
+
+  <category>
+    <name>ports</name>
+
+    <description>Ports</description>
+
+    <p>Changes affecting the Ports Collection, whether sweeping
+      changes that touch most of the tree, or individual ports
+      themselves.</p>
+  </category>
+
+  <category>
+    <name>doc</name>
+
+    <description>Documentation</description>
+
+    <p>Noteworthy changes in the documentation tree or new external
+      books/documents.</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>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/10.4R/announce.html">FreeBSD 10.4-RELEASE announcement</url>
+      <url href="https://www.FreeBSD.org/releases/11.2R/announce.html">FreeBSD 11.2-RELEASE announcement</url>
+      <url href="https://www.FreeBSD.org/releases/12.0R/schedule.html">FreeBSD 12.0-RELEASE schedule</url>
+      <url href="https://download.FreeBSD.org/ftp/snapshots/ISO-IMAGES/">FreeBSD development snapshots</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD Release Engineering Team responsibilities
+	include:</p>
+
+      <ul>
+	<li>setting and publishing release schedules for official
+	project releases</li>
+      </ul>
+
+      <p>of FreeBSD</p>
+
+      <ul>
+	<li>announcing code slushes, freezes, and thaws</li>
+
+	<li>maintaining the respective branches for all supported
+	releases</li>
+      </ul>
+
+      <p>
+	The FreeBSD Release Engineering Team, led by Marius
+	Strobl,
+	completed the 10.4-RELEASE in early October 2017. FreeBSD
+	10.4-RELEASE was the
+	fifth release from the <tt>stable/10</tt> branch, which
+	built on the
+	stability and reliability of 10.3-RELEASE.</p>
+
+      <p>The FreeBSD 11.2-RELEASE cycle started April 20, 2018 with
+	the
+	announcement of the code slush. The first stage progress
+	was
+	continued throughout the rest of the quarter with the code
+	freeze,
+	followed by three BETA builds, three RC builds, and the
+	final release
+	build was announced June 27, 2018.</p>
+
+      <p>The FreeBSD Release Engineering Team started the
+	12.0-RELEASE cycle
+	August 10, 2018 with the announcement of the code slush.
+	The code
+	freeze followed on August 24, 2018. The tentative date for
+	the <tt>stable/12</tt> branch was expected to be September 21,
+	2018.</p>
+
+      <p>
+	Due to unforeseen circumstances with upstream code that
+	was necessary
+	to include in 12.0-RELEASE, the tentative release schedule
+	needed
+	to be adjusted several times. The API changes in the
+	updated version
+	of the upstream code required changes to be made for all
+	base system
+	utilities that linked with the upstream code. By the end
+	of the
+	2018Q3 quarter, the <tt>stable/12</tt> branch had not been
+	created due to
+	this delay.</p>
+
+      <p>Throughout the remainder of 2018Q3, several development
+	snapshots builds
+	were released for the <tt>head</tt>, <tt>stable/11</tt>,
+	and <tt>stable/10</tt> branches.</p>
+
+      <p>Much of this work was sponsored by the FreeBSD Foundation.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>Ports Collection</title>
+
+    <contact>
+      <person>
+	<name>René Ladan</name>
+	<email>portmgr-secretary@FreeBSD.org</email>
+      </person>
+    </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>
+      <url href="@freebsd_portmgr)](https://twitter.com/freebsd_portmgr/">FreeBSD portmgr (@freebsd_portmgr)</url>
+      <url href="Facebook)](https://www.facebook.com/portmgr">FreeBSD Ports Management Team (Facebook)</url>
+      <url href="Google+)](https://plus.google.com/communities/108335846196454338383">FreeBSD Ports Management Team (Google+)</url>
+    </links>
+
+    <body>
+      <p>During the first quarter of 2018, the number of ports grew
+	to almost 32,000.
+	In 2018Q1, there were
+	2,100 open PRs with fewer than 600 unassigned. There were
+	7,900 commits from 169 committers. Compared to last
+	quarter, the number
+	of commits grew by 18% and the number of PRs dropped by
+	25%. Those are
+	some good numbers!</p>
+
+      <p>During the 2018Q2 and 2018Q3 quarters, the number of ports
+	grew to just under
+	34,000. The number of open PR grew to almost 2,500 with
+	fewer than 600
+	of those unassigned. A total of 175 committers made almost
+	14,200 commits.
+	Compared to the first quarter, the number of commits
+	dropped by 10% and
+	the number of PRs grew by 19%.</p>
+
+      <p>During the last three quarters, portmgr took twelve commit
+	bits in for
+	safekeeping: daichi@, deichen@, ian@, junovitch@, kevlo@,
+	maho@, nemysis@,
+	pawel@, rea@, tabthorpe@, vg@, and wxs@.</p>
+
+      <p>Portmgr welcomed thirteen new committers in 2018Q2 and
+	2018Q3:</p>
+
+      <ul>
+	<li>Devin Teske (dteske@)</li>
+
+	<li>Eric Turgeon (ericbsd@)</li>
+
+	<li>Fernando Apesteguía (fernape@)</li>
+
+	<li>Fukang Chen (loader@)</li>
+
+	<li>Gleb Popov (arrowd@)</li>
+
+	<li>Jesper Schmitz Mouridsen (jsm@)</li>
+
+	<li>John Hixson (jhixson@)</li>
+
+	<li>Kevin Bowling (kbowling@)</li>
+
+	<li>Koichiro IWAO (meta@)</li>
+
+	<li>Mateusz Piotrowski (0mp@)</li>
+
+	<li>Matthias Fechner (mfechner@)</li>
+
+	<li>Sergey Kozlov (skozlov@)</li>
+      </ul>
+
+      <p>
+	The following committers returned after a hiatus:</p>
+
+      <ul>
+	<li>Ion-Mihai Tetcu (itetcu@)</li>
+
+	<li>Kevin Lo (kevlo@)</li>
+
+	<li>Sean Chittenden (seanc@)</li>
+      </ul>
+
+      <p>
+	During the last three quarters, Antoine Brodin (antoine@)
+	ran no
+	fewer than 113 exp-runs against the ports tree. These runs
+	were
+	executed to test updates, perform cleanups, and make
+	improvements
+	to the framework and the base system. Most of the runs
+	were for
+	port upgrades, but others include LLD progress, changes to
+	the
+	default port versions, improved support for armv6, armv7,
+	and RISC-V
+	architectures, removed old base system functionality, new
+	USES, and
+	better matching pkg-plist with Makefile options (DOCS and
+	EXAMPLES).</p>
+
+      <p>Five new USES values were introduced:</p>
+
+      <ul>
+	<li>apache: handle dependencies on the Apache web server and
+	modules</li>
+
+	<li>eigen: automatically depend on math/eigen2 or math/eigen3</li>
+
+	<li>emacs: handle dependencies on the Emacs editor and
+	modules.</li>
+
+	<li>gl replaces the old USE_GL from bsd.port.mk</li>
+
+	<li>qt-dist, qt:4 and qt:5 replace the old USE_QT from
+	bsd.qt.mk</li>
+      </ul>
+
+      <p>
+	The EXTRA_PATCHES functionality has been extended to
+	support
+	directories, where it will automatically apply all
+	patch-\* files to the port.</p>
+
+      <p>Ports using USES=php:phpize, php:ext, php:zend, and
+	php:pecl have
+	been flavored and packages are now automatically built
+	for all
+	versions of PHP that are supported (5.6, 7.0, 7.1 or 7.2).</p>
+
+      <p>2018Q3 had updates of major ports: pkg 1.10.5, Chromium
+	65.0.3325.181, Firefox 59.0.2, Firefox-ESR 52.7.3, Ruby
+	2.3.7/2.5.1
+	and Qt5 5.9.4.
+	The default version of PHP was changed from 5.6 to 7.1.
+	The former
+	version of PHP is no longer supported by the developers.
+	The
+	default versions of Samba and GCC are now respectively 4.7
+	and 7. The
+	Xorg ports have been reorganized and there have been
+	changes to
+	net/openntpd. Please review the UPDATING file for relevant
+	details.</p>
+
+      <p>Open tasks:</p>
+
+      <ul>
+	<li>The number of commits dropped somewhat over the last three
+	quarters,
+	leaving more PRs unresolved. If possible, please pick up
+	some PRs
+	and improve everyone's experience.</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>Core Team</title>
+
+    <contact>
+      <person>
+	<name>FreeBSD Core Team</name>
+	<email>core@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Much of Core's focus for the past months has been on three
+	items:</p>
+
+      <p>1. Coordination between different groups to support the
+	upcoming 12.0 release. The timing of the OpenSSL
+	1.1.1 release posed challenges, the new OpenSSL
+	version included API changes, many components of
+	the base system and ports required changes.
+	Staying with the older OpenSSL in 12.0 was not a
+	feasible option, because it would have meant
+	backporting many changes to a version of OpenSSL
+	that would be unmaintained by the upstream source.</p>
+
+      <p>2. Discussions with the release engineering team and Scott
+	Long about updating the FreeBSD release process.
+	Topics for exploration include:</p>
+
+      <ul>
+	<li>having more frequent point releases</li>
+
+	<li>changing the support model</li>
+
+	<li>revising and improving the tooling used to manage the tree
+	and releases</li>
+
+	<li>additional topics as they are discovered</li>
+      </ul>
+
+      <p>3. Gathering information to make decisions more
+	data-driven. For example, we are planning
+	developer and user surveys. If there are questions
+	that you think should be added to the survey,
+	please discuss them on freebsd-arch@. We are
+	exploring ways for automated user-driven hardware
+	usage data to understand the changing ways our
+	software is used and to target better hardware
+	support.</p>
+
+      <p>Here are other noteworthy events (in chronological order)
+	since the last quarterly report.</p>
+
+      <p>2017 Q4</p>
+
+      <ul>
+	<li>Sean Eric Fagan's (sef@) commit bit was reactivated with a
+	period of re-mentoring under Alexander Motin
+	(mav@).</li>
+
+	<li>The MIPS architecture was promoted to tier 2 status.</li>
+
+	<li>Core approved changes to the Code of Conduct.</li>
+
+	<li>All fortune data files, except freebsd-tips, were removed
+	in r325828.</li>
+
+	<li>Core approved the adoption of a policy requiring any
+	license exceptions to be recorded alongside code.</li>
+
+	<li>Gordon Tetlow (gordon@) became the new security officer.</li>
+
+	<li>Core approved the use of SPDX tags.</li>
+      </ul>
+
+      <p>
+	2018 Q1</p>
+
+      <ul>
+	<li>Jeb Cramer (jeb@) was awarded a src commit bit under the
+	mentorship of Sean Bruno (sbruno@) and Eric Joyner
+	(erj@).</li>
+
+	<li>Members of the CoC Review Team were approved. The
+	membership is to be reviewed once per year.</li>
+
+	<li>A vendor commit bit was awarded to Slava Shwartsman
+	(slavash@) of Mellanox Technologies under the
+	mentorship of Konstantin Belousov (kib@) and Hans
+	Petter Selasky (hselasky@).</li>
+
+	<li>Walter Schwarzenfeld was awarded project membership.</li>
+
+	<li>Brad Davis (brd@) was awarded a src commit bit under the
+	mentorship of Allan Jude (allanjude@) with
+	Baptiste Daroussin (bapt@) as co-mentor.</li>
+
+	<li>Vincenzo Maffione (vmaffione@) was awarded a src commit
+	bit under the mentorship of Hiroki Sato (hrs@).</li>
+
+	<li>Ram Kishore Vegesna (ram@) was awarded a src commit bit
+	under the mentorship of Kenneth D. Merry (ken@)
+	and Alexander Motin (mav@).</li>
+      </ul>
+
+      <p>2018 Q2</p>
+
+      <ul>
+	<li>Tom Jones (thj@) was awarded a src commit bit under the
+	mentorship of Jonathan T. Looney (jtl@).</li>
+
+	<li>Matt Macy's (mmacy@) commit bit was restored under the
+	mentorship of Sean Bruno (sbruno@).</li>
+
+	<li>Breno Leitao (leitao@) was awarded a src commit bit under
+	the mentorship of Justin Hibbits (jhibbits@) with
+	Nathan Whitehorn (nwhitehorn@) as co-mentor.</li>
+
+	<li>Leandro Lupori (luporl@) was awarded a src commit bit
+	under the mentorship of Justin Hibbits (jhibbits@)
+	with Nathan Whitehorn (nwhitehorn@) as co-mentor.</li>
+
+	<li>The handover from the ninth to the tenth elected Core team
+	took place. The tenth Core members are: Allan Jude
+	(allanjude@), Benedict Reuschling (bcr@), Brooks
+	Davis (brooks@), Hiroki Sato (hrs@), Warner Losh
+	(imp@), Jeff Roberson (jeff@), John Baldwin
+	(jhb@), Kris Moore (kmoore@), and Sean Chittenden
+	(seanc@).</li>
+
+	<li>Joseph Mingrone (jrm@) was appointed the Core secretary
+	under mentorship of the retiring Core secretary,
+	Matthew Seaman (matthew@).</li>
+
+	<li>The new team liaisons were decided. portmgr: Sean, doceng:
+	Hiroki, secteam: Brooks, re: John, clusteradm:
+	Allan, CoC: Warner, Foundation: Benedict,
+	bugmeister: John, CI: Sean.</li>
+
+	<li>David Maxwell (dwm@) was awarded project membership.</li>
+
+	<li>Daichi Goto's (daichi@) commit bit was reactivated with a
+	period of re-mentoring under George Neville-Neil
+	(gnn@).</li>
+
+	<li>A vendor commit bit was awarded to Ben Widawsky
+	(bwidawsk@) of Intel under the mentorship of Ed
+	Maste (emaste@).</li>
+      </ul>
+
+      <p>
+	2018 Q3</p>
+
+      <ul>
+	<li>Core decided to begin meeting twice per month in an
+	attempt to catch up with many new agenda items.</li>
+
+	<li>Li-Wen Hsu (lwhsu@) was awarded a src commit bit under the
+	mentorship of Mark Johnston (markj@) with Ed Maste
+	(emaste@) as co-mentor.</li>
+
+	<li>Samy al Bahra was awarded project membership.</li>
+
+	<li>George Neville-Neil (gnn@) was approved to begin
+	co-mentoring Vincenzo Maffione (vmaffione@).</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>The 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, quality assurance, and release
+	engineering efforts; publishes marketing material
+	to promote, educate, and advocate for the FreeBSD
+	Project; facilitates collaboration between
+	commercial vendors and FreeBSD developers; and
+	finally, represents the FreeBSD Project in
+	executing contracts, license agreements, and other
+	legal arrangements that require a recognized legal
+	entity.</p>
+
+      <p>Here are some highlights of what the FreeBSD Foundation
+	did to help FreeBSD last quarter:</p>
+
+      <p>Partnerships and Commercial User Support</p>
+
+      <p>As a 501(c)(3) non-profit, we don't directly support
+	commercial users, but we do work with them to
+	understand their needs and help facilitate
+	collaboration with the community. Last quarter we
+	met with a few key FreeBSD users and supporters,
+	to discuss pain points, how they can contribute
+	back to FreeBSD, and what technologies they would
+	like to see supported, to support FreeBSD over
+	more of their technologies and products.</p>
+
+      <p>As many of you know, we formed a partnership with Intel
+	around one and a half years ago. Since then the
+	people we worked directly with left the company,
+	but it moved us into a new relationship with their
+	Open Source Technology Center (OTC).</p>
+
+      <p>We are very encouraged that Intel has dedicated additional
+	resources from the OTC to work on FreeBSD in
+	addition to existing resources from the networking
+	group and other technologies such as QuickAssist.
+	Much of the work has been focused on security and
+	OS mitigations but we're also focusing on other
+	areas such as power management and persistent
+	memory. In May and again in July we traveled to
+	Intel's Hillsboro campus to meet with management
+	and engineers from OTC and the networking team. We
+	presented an overview of the project and
+	Foundation and also discussed key markets and
+	vendors who use FreeBSD in their products or
+	services and their future requirements.</p>
+
+      <p>Intel was also interested in learning more about who
+	contributes to FreeBSD. Along those lines we've
+	done some work with OTC to create scripts and
+	organizational mappings to answer that question.
+	Note that we do need developers
+	to help us update and maintain the organizational
+	mappings as we understand that developers do tend
+	to move around and contractors are often working
+	on behalf of multiple organizations.</p>
+
+      <p>Fundraising Efforts</p>
+
+      <p>Our work is 100% funded by your donations. As of September
+	30, we raised $328,482. Our 2018 fundraising goal
+	is $1,250,00 and we are continuing to work hard to
+	meet and exceed this goal! Please consider making
+	a donation to help us continue and increase our
+	support for FreeBSD: <a
+	href="https://www.FreeBSDfoundation.org/donate/">https://www.FreeBSDfoundation.org/donate/</a>.</p>
+
+      <p>We also have a new 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/">https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/</a>
+	and share with your companies!</p>
+
+      <p>OS Improvements</p>
+
+      <p>The Foundation improves the FreeBSD operating system by
+	employing technical staff to maintain and improve
+	critical kernel subsystems, add features and
+	functionality, and fix problems. This also
+	includes funding separate project grants like the
+	arm64 port, porting the blacklistd access control
+	daemon, and the integration of VIMAGE support, to
+	make sure that FreeBSD remains a viable solution
+	for research, education, computing, products and
+	more.</p>
+
+      <p>We kicked off or continued the following projects last
+	quarter:</p>
+
+      <ul>
+	<li>OpenZFS RAID-Z Expansion project</li>
+
+	<li>Headless mode out-of-the-box for embedded ARM boards like
+	the Beaglebone Black</li>
+
+	<li>Performance and scalability improvements</li>
+      </ul>
+
+      <p>
+	Having software developers on staff has allowed us to jump
+	in and work directly on projects to improve
+	FreeBSD such as:</p>
+
+      <ul>
+	<li>ZFS improvements</li>
+
+	<li>New Intel server support</li>
+
+	<li>kqueue(2) updates</li>
+
+	<li>64-bit inode support</li>
+
+	<li>Stack guard</li>
+
+	<li>Kernel Undefined Behavior Sanitizer</li>
+
+	<li>Toolchain projects</li>
+
+	<li>i915 driver investigation</li>
+
+	<li>NVDIMM support in acpiconf(8)</li>
+
+	<li>Continuous integration dashboard (web page and physical
+	hardware)</li>
+
+	<li>FAT filesystem support in makefs(8)</li>
+      </ul>
+
+      <p>
+	Continuous Integration and Quality Assurance</p>
+
+      <p>The Foundation provides a full-time staff member who is
+	working on improving our automated testing,
+	continuous integration, and overall quality
+	assurance efforts.</p>
+
+      <p>Foundation employee Li-Wen Hsu set up new CI servers to
+	speed up amd64 build and test jobs, to reduce the
+	latency between changes being committed and
+	results being available. Li-Wen also set up a
+	staging / development server in order to test
+	changes to the CI system itself without affecting
+	production results. We have also started a small
+	hardware test lab, currently connected to the
+	staging server, that tests the full boot and test
+	cycle on physical hardware. In the near future
+	additional hardware devices will be added, and
+	this will migrate to the production CI server.</p>
+
+      <p>Release Engineering</p>
+
+      <p>The Foundation provides a full-time staff member to lead
+	the release engineering efforts. This has provided
+	timely and reliable releases over the last five
+	years.</p>
+
+      <p>Foundation employee Glen Barber continued leading the
+	efforts on the upcoming 12.0-RELEASE. For details
+	surrounding the work involved and progress thus
+	far on 12.0-RELEASE, please see the FreeBSD
+	Release Engineering Team section of this quarterly
+	status report.</p>
+
+      <p>Supporting FreeBSD Infrastructure</p>
+
+      <p>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</p>
+
+      <p>A large part of our efforts are dedicated to advocating
+	for the Project. This includes promoting work
+	being done by others with FreeBSD; producing
+	advocacy literature to teach people about FreeBSD
+	and help make the path to starting using FreeBSD
+	or contributing to the Project easier; and
+	attending and getting other FreeBSD contributors
+	to volunteer to run FreeBSD events, staff FreeBSD
+	tables, and give FreeBSD presentations.</p>
+
+      <p>The FreeBSD Foundation sponsors many conferences, events,
+	and summits around the globe. These events can be
+	BSD-related, open source, or technology events
+	geared towards underrepresented groups. We support
+	the FreeBSD-focused events to help provide a venue
+	for sharing knowledge, to work together on
+	projects, and to facilitate collaboration between
+	developers and commercial users. This all helps
+	provide a healthy ecosystem. We support the
+	non-FreeBSD events to promote and raise awareness
+	of FreeBSD, to increase the use of FreeBSD in
+	different applications, and to recruit more
+	contributors to the Project.</p>
+
+      <p>Check out some of the advocacy and education work we did
+	last quarter:</p>
+
+      <ul>
+	<li>Organized and ran the Essen FreeBSD Hackathon in Essen,
+	Germany</li>
+
+	<li>Participated in the FreeBSD Developer Summit BSDCam, in
+	Cambridge, England</li>
+
+	<li>Represented FreeBSD at the ARM Partner Meeting</li>
+
+	<li>Presented and taught about FreeBSD at SdNOG 5 in Khartoum,
+	Sudan</li>
+
+	<li>Exhibited and gave a talk at OSCON 2018 in Portland, OR</li>
+
+	<li>Exhibited at the 2018 Grace Hopper Celebration and
+	sponsored as a Silver Non-Profit Sponsor</li>
+
+	<li>Exhibited at COCON 2018 in Taipei, Taiwan</li>
+
+	<li>Sponsored and gave presentations and tutorials at
+	EuroBSDCon in Bucharest, Romania</li>
+
+	<li>Organized and ran the Bucharest FreeBSD Developer Summit</li>
+
+	<li>Sponsored the 2018 USENIX Security Symposium in Baltimore,
+	MD as an Industry Partner</li>
+
+	<li>Provided FreeBSD advocacy material</li>
+
+	<li>Sponsored the 2018 USENIX Annual Technical Conference in
+	Boston, MA as an Industry Partner</li>
+
+	<li>Sponsored the OpenZFS Developer Summit as a Silver Sponsor</li>
+
+	<li>Presented and taught about FreeBSD at SANOG32 in Dhaka,
+	Bangladesh</li>
+
+	<li>Sponsored the SNIA Storage Developer Conference 2018 as an
+	Association Partner</li>
+
+	<li>Provided 11 travel grants to FreeBSD contributors to
+	attend many of the above events.</li>
+      </ul>
+
+      <p>
+	We continued producing FreeBSD advocacy material to help
+	people promote FreeBSD around the world.</p>
+
+      <p>Read more about our conference adventures in the
+	conference recaps and trip reports in our monthly
+	newsletters: <a
+	href="https://www.freebsdfoundation.org/news-and-events/newsletter/">https://www.freebsdfoundation.org/news-and-events/newsletter/</a></p>
+
+      <p>We help educate the world about FreeBSD by publishing the
+	professionally produced FreeBSD Journal. Last
+	quarter we published the July/August issue that
+	you can find at <a
+	href="https://www.FreeBSDfoundation.org/journal/">https://www.FreeBSDfoundation.org/journal/</a>.</p>
+
+      <p>You can find out more about events we attended and
+	upcoming events at <a
+	href="https://www.FreeBSDfoundation.org/news-and-events/">https://www.FreeBSDfoundation.org/news-and-events/</a>.</p>
+
+      <p>Legal/FreeBSD IP</p>
+
+      <p>The Foundation owns the FreeBSD trademarks, and it is our
+	responsibility to protect them. We also provide
+	legal support for the core team to investigate
+	questions that arise.</p>
+
+      <p>Go to <a
+	href="http://www.FreeBSDfoundation.org">http://www.FreeBSDfoundation.org</a>
+	to find out how we support FreeBSD and how we can
+	help you!</p>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>Continuous Integration</title>
+
+    <contact>
+      <person>
+	<name>Jenkins Admin</name>
+	<email>jenkins-admin@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Li-Wen Hsu</name>
+	<email>lwhsu@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url>
+      <url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url>
+      <url href="https://wiki.FreeBSD.org/Jenkins">FreeBSD Jenkins wiki</url>
+      <url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url>
+      <url href="https://github.com/freebsd/freebsd-ci">freebsd-ci Repository</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD CI team maintains continuous integration tasks
+	for FreeBSD. The CI
+	system regularly checks the changes committed to the
+	project's Subversion
+	repository can be successfully built, and performs various
+	tests and analysis
+	with the build results. The CI team also maintains the
+	archive of the artifact
+	built by the CI system, for the further testing and
+	debugging needs.</p>
+
+      <p>Starting from June 2018, the project is sponsored by the
+	FreeBSD Foundation in
+	hardware and staff. For more details of the sponsored
+	projects, please refer
+	to:</p>
+
+      <p><a
+	href="https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-september-2018/">https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-september-2018/</a></p>
+
+      <p>In addition to that, we also helped checking regressions
+	for OpenSSL 1.1.1
+	update and test continuously for 12-STABLE branch.</p>
+
+      <p>We had meetings and working groups at two developer
+	summits during 2018Q3:</p>
+
+      <ul>
+	<li><a
+	href="https://wiki.FreeBSD.org/DevSummit/201808/Testing">BSDCam
+	2018</a></li>
+
+	<li><a
+	href="https://wiki.FreeBSD.org/DevSummit/201809">EuroBSDCon
+	2018</a></li>
+      </ul>
+
+      <p>
+	Work in progress:</p>
+
+      <ul>
+	<li>Fixing the failing test cases and builds</li>
+
+	<li><a
+	href="https://ci.FreeBSD.org/job/FreeBSD-head-amd64-dtrace_test/lastCompletedBuild/testReport/">DTrace
+	test</a></li>
+
+	<li><a
+	href="https://ci.FreeBSD.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/">ZFS
+	test</a></li>
+
+	<li><a
+	href="https://ci.FreeBSD.org/job/FreeBSD-head-amd64-gcc/">GCC
+	build</a></li>
+
+	<li>Adding drm ports building test against -CURRENT</li>
+
+	<li>Adding tests for selected project branches, e.g.:
+	clang700-import</li>
+
+	<li>Adding new hardware to the embedded testbed</li>
+
+	<li>Implementing automatic tests on bare metal hardware</li>
+
+	<li>Planning running ztest and network stack tests</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>4G/4G address space split for i386</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Most 32-bit FreeBSD architectures, including i386, started
+	to suffer
+	from the rapid growth of the size of software during the
+	past decade.
+	When a 32-bit address space is enough space for a given
+	task, 32-bit
+	mode still has an intrinsic advantage over 64-bit mode,
+	due to less
+	memory traffic and more economical use of caches. It has
+	grown
+	harder to provide the self-hosting i386 system build due
+	to the
+	increase in size of the build tools.</p>
+
+      <p>The FreeBSD i386 kernel, prior to the 12.0-RELEASE
+	version, split
+	the 4GB address space of the platform into 3GB (minus 4MB)
+	accessible
+	to userspace accesses and 1GB for kernel accesses.
+	Neither kernel nor userspace could access a full 4GB
+	address space.
+	Programs that require very large virtual address spaces,
+	such as
+	clang when compiling or lld when linking, could run out of
+	address
+	space: 3GB of address space was insufficient for their
+	operation.
+	The kernel also had trouble fitting into the traditional
+	1GB
+	limitation of address space with the modern sizing for
+	network
+	buffers, ZFS and other KVA-hungry in-kernel subsystems.</p>
+
+      <p>In FreeBSD 12, the i386 architecture has been changed to
+	provide
+	dedicated separate address spaces for userspace and
+	kernel, giving
+	each mode full access to 4GB (minus 8MB) of usable address
+	space.
+	The userspace on the i386 architecture now has access to
+	the same
+	amount of address space as the compat32 subsystem in the
+	amd64
+	architecture kernel. The increase in kernel address space
+	enables
+	further growth and maintainability of the i386
+	architecture.</p>
+
+      <p>The split 4GB/4GB user/kernel implementation uses two page
+	directory
+	entries (PDEs) shared between modes: one for mapping the
+	page table,
+	another for the mode switching trampoline and other
+	required system
+	tables. The required system tables, which must always be
+	mapped,
+	regardless of kernel or user mode, includes such things as
+	the
+	GDT/IDT/TSS entries. Significant changes were made to the
+	locore
+	code. The page table creation portion of the code was
+	completely
+	rewritten from assembly to C, improving readability and
+	maintainability
+	of the code.</p>
+
+      <p>Because the user address space is no longer shared with
+	the kernel,
+	the copyout(9) functions were rewritten to make a
+	transient mapping
+	of userspace pages for the duration of any needed
+	accesses. The initial
+	implementation used the vm_fault_quick_hold_pages()
+	framework, but
+	this was later optimized by temporarily switching to user
+	mode
+	mappings from a trampoline, and then using hand-written
+	assembler
+	routines to perform a faster small block copy operation.</p>
+
+      <p>Future plans for the ongoing maintenance of i386 include
+	making the i386 pmap
+	capable of runtime selection of the PAE or non-PAE page
+	table format
+	and supporting NX (no execute) mappings for regular i386
+	kernel.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>FreeBSD/DTrace</title>
+
+    <contact>
+      <person>
+	<name>George Neville-Neil</name>
+	<email>gnn@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Domagoj Stolfa</name>
+	<email>domagoj.stolfa@cl.cam.ac.uk</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>DTrace is a whole-system debugging tool in FreeBSD and is
+	one of the
+	actively supported projects during the past year.</p>
+
+      <p>A research prototype of a distributed version of DTrace
+	and a version
+	of DTrace that can trace bhyve virtual machines from the
+	host FreeBSD
+	system are currently under development at the University
+	of Cambridge
+	as a part of the CADETS project. Recent developments
+	include the
+	creation of dlog, an in-kernel DTrace consumer which is
+	able to
+	publish to Kafka, and improvements to early boot and
+	shutdown tracing.
+	On the virtualisation front,
+	improvements were made in the ability to dereference and
+	follow
+	pointers inside guests from the host in the probe context
+	by
+	implementing a nested page table walk inside DTrace for
+	Intel
+	architectures. The CADETS project has started formalizing
+	DTrace in HOL4 which enables automated test generation,
+	high assurance
+	of DTrace implementations in terms of adherence to the
+	specification
+	and exploration of all allowable behaviors for a given D
+	script. Currently, the formal model contains most of DIF
+	instructions
+	and a code generator for them, providing the ability to
+	run DIF
+	programs specified using the model using FreeBSD's DTrace
+	implementation.</p>
+
+      <p>As a result of all of this, a number of changes were
+	upstreamed to the
+	FreeBSD auditing subsystem and new variables such as
+	<tt>jid</tt> and
+	<tt>jailname</tt> were added to DTrace which can be
+	accessed from D scripts.</p>
+
+      <p>OpenDTrace Specification 1.0 has been published which
+	covers the
+	internal workings of DTrace in general, and its adaptation
+	to various
+	operating systems in particular. This work was sponsored
+	by
+	AFRL/DARPA through the CADETS project.</p>
+
+      <p>Ruslan Bukin (br@) has added C-compressed ISA extension
+	support to the
+	RISC-V FBT provider as a part of the ECATS project.</p>
+
+      <p>Mark Johnston (markj@) has done some work to fix
+	interactions between
+	FBT and ifuncs. ifuncs are a toolchain feature which allow
+	programmers
+	to select a function's implementation at boot-time, rather
+	than at
+	compile-time. For instance, on amd64, memcpy() is an ifunc
+	and may be
+	implemented by either memcpy_erms() or memcpy_std(). FBT
+	created
+	probes for the implementation functions, but we needed
+	some extra
+	support to ensure that fbt::memcpy:entry continues to work
+	as
+	expected. Similar work is needed for the PID provider, but
+	is still
+	pending.</p>
+
+      <p>Microsoft showed a <a
+	href="https://youtu.be/tG8R5SQGPck?t=891">working
+	demo of DTrace</a>,
+	which was ported from FreeBSD.</p>
+
+      <p>Added to FreeBSD base in 11.2, dwatch is a new DTrace
+	tool, developed
+	by Devin Teske (dteske@), for automating complex queries
+	for data and
+	surgically tapping the kernel. In base there are 85
+	profiles for
+	interpreting domain-specific data with another 17
+	available from ports
+	making a total of over 100 different pipelines from which
+	you can
+	extract data in multiple formats. dwatch also simplifies
+	observation
+	of over 100,000 probe points available in FreeBSD, making
+	it easy to
+	find any process, thread, or jail triggering any probe.
+	On top of all
+	that, dwatch profiles can leverage higher-level languages
+	such as
+	python, perl, sh, and many more.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>ACPI NVDIMM driver</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>NVDIMM is a technology which provides non-volatile memory
+	with
+	access characteristics similar to regular DRAM, which is
+	the
+	technology that implements the normal memory address space
+	of a host.
+	There are ACPI and UEFI specifications that define
+	platform independent
+	ways to detect and enumerate the presence of NVDIMMs.
+	These
+	specifications allow the retrieval of most of the data
+	needed to
+	allow proper application use of the NVDIMM storage.</p>
+
+      <p>A new FreeBSD driver parses the ACPI NFIT table which
+	lists NVDIMMs,
+	their operational characteristics, and the physical
+	address space
+	where the NVDIMM memory is accessible. The driver presents
+	each
+	address region as two devices: One device allows userspace
+	to
+	open(2) a devfs node, which can be read/written/mapped
+	from the
+	application. This mapping is zero-copy. The second device
+	is a
+	geom disk(9), which makes it possible to use NVDIMM for
+	the backing
+	storage for a normal FreeBSD filesystem, such as UFS, ZFS,
+	or msdosfs.
+	Note that buffer cache/mapping of files from a traditional
+	filesystem
+	created over NVDIMM causes an unneeded double-buffering.</p>
+
+      <p>Empirically, on typical modern hardware, NVDIMM regions
+	are located
+	far from the regular DRAM backed memory in the address
+	space, and
+	have attributes that are not compatible with regular DRAM
+	memory.
+	This makes it unfeasible to extend the kernel's direct map
+	to provide
+	the kernel mappings for the NVDIMM regions.
+	A new pmap KPI was designed, pmap_large_map(9),
+	which allows efficient mapping of very large physical
+	regions into
+	the KVA. The new code has some optimizations to the cache
+	flushing
+	operations over the mapped regions, which is needed to
+	efficiently
+	support bio flushes from a filesystems using the NVDIMM
+	storage.
+	The NVDIMM driver is the first user of the new KPI,
+	but the new KPI might also be useful for the NTB driver.</p>
+
+      <p>
+	TODO:</p>
+
+      <ul>
+	<li>Intel is currently working on extending the driver to
+	support
+	UEFI namespaces.</li>
+      </ul>
+
+      <ul>
+	<li>A DAX-capable filesystem is needed, which solves the issue
+	of
+	double-buffering. Our tmpfs already provides VM facilities
+	which
+	allows it to avoid double-buffering for mmap, which can be
+	reused
+	there.</li>
+      </ul>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>SMAP</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Support for SMAP (Supervisor-Mode Access Prevention), has
+	been added
+	to the amd64 kernel. The SMAP feature makes any access
+	from the
+	supervisor mode to the pages accessible to user mode cause
+	a fault,
+	unless the %eflags.AC bit is set at the time of the
+	access.</p>
+
+      <p>The SMAP implementation uses the ifunc framework to avoid
+	checking
+	for the SMAP capability of hardware on each call to
+	copyout(9) and
+	other functions.</p>
+
+      <p>In the amd64 architecture, FreeBSD has a common address
+	space between
+	the kernel space and user space. Enabling SMAP virtually
+	splits
+	the shared address space into two disjoint address spaces,
+	which
+	have different access criteria. This splitting of the
+	address space
+	provides a relatively low-overhead way of catching direct
+	accesses
+	from kernel to usermode, when not using the copyout(9)
+	family of
+	functions. The copyout(9) family of functions are
+	permitted direct
+	access to user space. Any direct access from kernel mode
+	to user
+	address space that isn't performed through the copyout(9)
+	family
+	of functions indicates a potential programming error.</p>
+
+      <p>It is interesting that very few bugs were found in the
+	FreeBSD
+	kernel after the SMAP feature was enabled. One issue that
+	was
+	identified existed in the pci(9) user driver. Enabling the
+	SMAP
+	feature identified at least two ports, VBox and acpi_call,
+	which
+	appeared to access userspace in an unsafe manner.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Large scale package building</title>
+
+    <contact>
+      <person>
+	<name>Mateusz Guzik</name>
+	<email>mjg@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Building packages on a 128-thread machine with poudriere
+	exhibits some
+	bottlenecks.</p>
+
+      <p>See the October FreeBSD Foundation Newsletter for a short
+	write-up:
+	<a
+	href="https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-october-2018/">https://www.freebsdfoundation.org/news-and-events/newsletter/freebsd-foundation-update-october-2018/</a></p>
+
+      <p>One encountered problem stems from process handling.</p>
+
+      <p>The standard process life cycle on UNIX-like systems looks
+	like this:</p>
+
+      <ul>
+	<li>a process is created with fork(2)</li>
+
+	<li>it can do regular work or execve(2) a new binary</li>
+
+	<li>it exits, becoming a zombie</li>
+
+	<li>the parent collects the exit code and removes the zombie</li>
+      </ul>
+
+      <p>
+	There are other variations (e.g. vfork(2) can be used
+	instead of
+	fork).</p>
+
+      <p>When you type 'ls' into your shell, it will typically
+	vfork a new process
+	which will then execve /bin/ls.</p>
+
+      <p>All this is guarded with several global kernel locks, but
+	the granularity
+	can be significantly improved.</p>
+
+      <p>A different problem stems from pipes.</p>
+
+      <p>Pipes are used all the time, e.g. "du -s | sort -n"
+	creates a pipe whose
+	one endpoint is standard output for du and another is
+	standard input for sort.</p>
+
+      <p>By default the pipe can hold up to 16KB before it gets
+	filled up.</p>
+
+      <p>The kernel dedicates part of its virtual address space to
+	hold pipe buffers
+	and allocates/deallocates physical pages as pipes get
+	created/destroyed.
+	This induces TLB invalidation requests to other CPUs,
+	which causes an
+	unnecessary slowdown.</p>
+
+      <p>An easy way out is to cache a certain number of buffers.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>String functions on the amd64 architecture</title>
+
+    <contact>
+      <person>
+	<name>Mateusz Guzik</name>
+	<email>mjg@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Functions like memset, memmove and memcpy are very
+	frequently used by virtually
+	all programs. They can be optimized in various ways, but
+	FreeBSD uses very
+	rudimentary implementations using rep movsq/stosq. rep
+	prefix has high startup
+	latency which is overly expensive when dealing with small
+	sizes.</p>
+
+      <p>Short term goal of this project is to implement faster
+	variants for the kernel
+	and import them into libc. The main speed up comes from
+	not using rep for small
+	sizes (&lt; 256) and from aligning target buffers to 16
+	bytes when rep is used.
+	On top of that runtime detection of the Enhanced REP
+	MOVSB/STOSB extention can
+	be used to only use rep movsb/stosb.</p>
+
+      <p>Mid term goal extends userspace. SIMD extensions can be
+	used to make these functions
+	faster. They can't easily be used in the kernel: SIMD
+	registers are not saved on
+	transitions user&lt;-&gt;kernel for performance reasons.
+	Thus any use would have to
+	take care of saving these registers, which can consume any
+	advantage from using them in
+	the first place. This is not a concern for userspace code.</p>
+
+      <p>There is a BSD-licensed implementation in bionic:
+	<a
+	href="https://android.googlesource.com/platform/bionic/+/master/libc/arch-x86_64/string/">https://android.googlesource.com/platform/bionic/+/master/libc/arch-x86_64/string/</a></p>
+
+      <p>which with some modifications can be used in libc later
+	on.</p>
+
+      <p>See the Intel Optimization Manual for reference:
+	<a
+	href="https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf">https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf</a></p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>32-bit compatibility and other ABI cleanups</title>
+
+    <contact>
+      <person>
+	<name>Brooks Davis</name>
+	<email>brooks@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>As part of maintaining an external ABI (application binary
+	interface)
+	compatibility layer, I've been improving FreeBSD
+	infrastructure,
+	primarily the 32-bit compatibility layer. One of FreeBSD's
+	strengths is
+	that we can easily support many ABIs. This includes
+	support for a.out
+	format executables (vs the standard ELF), support for i386
+	on amd64, the
+	Linux emulation layer, etc.</p>
+
+      <p>This infrastructure has existed for decades and not every
+	design
+	decision has stood the test of time. Support has also been
+	incomplete
+	in a number of areas (e.g. network management under 32-bit
+	emulation).</p>
+
+      <p>Committed improvements include:</p>
+
+      <ul>
+	<li>Improved <tt>ioctl</tt> and <tt>sysctl</tt> support to
+	allow <tt>ifconfig</tt> and
+	<tt>netstat</tt> to work in 32-bit compat mode.</li>
+      </ul>
+
+      <ul>
+	<li>Migration from a model of translating <tt>ioctl</tt>
+	commands and data
+	structures at the kernel boundary to translating where the
+	commands
+	are processed. This is a correctness improvement (`ioctl`
+	commands
+	do not have meaning outside the specific file descriptor
+	in question)
+	and improves code reusability (my out-of-tree work will
+	soon include
+	a 64-bit compatibility layer.)</li>
+      </ul>
+
+      <ul>
+	<li>Simplifications of the generic ELF process execution path
+	by Ed
+	Maste, John Baldwin, and myself. A number of
+	simplifications including
+	minor speedups have been committed.</li>
+      </ul>
+
+      <p>
+	Portions of this work were developed by SRI International
+	and the
+	University of Cambridge Computer Laboratory (Department of
+	Computer
+	Science and Technology) under DARPA/AFRL contract
+	FA8750-10-C-0237
+	("CTSRD"), as part of the DARPA CRASH research programme
+	and under DARPA
+	contract HR0011-18-C-0016 ("ECATS"), as part of the DARPA
+	SSITH research
+	programme.</p>
+
+      <p>Work in progress includes cleanups to the APIs used by the
+	kernel when
+	creating processes and continued <tt>ioctl</tt>
+	improvements. Work is also
+	underway to generate the 32-bit system call list from the
+	"default"
+	list.</p>
+
+      <p>The remaining <tt>ioctl</tt> commands handled in
+	<a
+	href="https://svnweb.FreeBSD.org/base/head/sys/compat/freebsd32/freebsd32_ioctl.c?view=log">sys/compat/freebsd32/freebsd32_ioctl.c</a>
+	need to be migrated to the point of implementation. Help
+	with the latter
+	would be appreciated.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Save/Restore/Migration support in bhyve</title>
+
+    <contact>
+      <person>
+	<name>Elena Mihailescu</name>
+	<email>elenamihailescu22@gmail.com</email>
+      </person>
+      <person>
+	<name>Darius Mihai</name>
+	<email>dariusmihaim@gmail.com</email>
+      </person>
+      <person>
+	<name>Sergiu Weisz</name>
+	<email>sergiu121@gmail.com</email>
+      </person>
+      <person>
+	<name>Mihai Carabas</name>
+	<email>mihai@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migration">Github repository for the save/restore and migration features</url>
+      <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Save-and-Restore-a-virtual-machine-using-bhyve">Github wiki - How to Save and Restore a bhyve guest</url>
+      <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Virtual-Machine-Migration-using-bhyve">Github wiki - How to Migrate a bhyve guest</url>
+      <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Suspend-Resume-test-matrix">Github wiki - Suspend/resume test matrix</url>
+    </links>
+
+    <body>
+      <p>The Save/Restore feature is a facility to suspend and
+	resume guest
+	virtual images that has been added to the FreeBSD/amd64's
+	hypervisor,
+	bhyve. The bhyvectl tool is used to save the guest virtual
+	machine
+	into three files:</p>
+
+      <ul>
+	<li>a file for the guest memory</li>
+
+	<li>a file for state of each device / CPU state</li>
+
+	<li>a file that has metadata that is used in the restore
+	process</li>
+      </ul>
+
+      <p>
+	To suspend a bhyve guest, the bhyvectl tool must be run
+	with the <tt>--suspend
+	&lt;state_file_name&gt;</tt>
+	option followed by the guest name.</p>
+
+      <p>To restore a bhyve guest from a checkpoint, one simply has
+	to add the <tt>-r</tt> option
+	followed by the main state file (the same file that was
+	given to the <tt>--suspend</tt>
+	option for bhyvectl) when starting the VM.</p>
+
+      <p>The Migration feature uses the Save/Restore implementation
+	to migrate a bhyve guest
+	from one FreeBSD host to another FreeBSD host. To migrate
+	a bhyve guest,
+	one needs to start an empty guest on the destination host
+	from a shared guest
+	image using the bhyve tool with the <tt>-R</tt> option
+	followed by the source host
+	IP and the port to listen to migration request. On the
+	source host, the
+	migration is started by executing the bhyvectl command
+	with the <tt>--migrate</tt>
+	option, followed by the destination host IP and the port
+	to send to the messages.</p>
+
+      <p>New features added:</p>
+
+      <ul>
+	<li>Create the socket connection between source and
+	destination hosts</li>
+
+	<li>Migrate the guest state via sockets</li>
+
+	<li>Separate the suspend/resume/migration code from the
+	bhyverun.c and bhyvectl.c and added two new files
+	for them: migration.c and migration.h</li>
+
+	<li>Added save/restore state for xhci</li>
+
+	<li>Added save/restore state for fbuf</li>
+
+	<li>Fix vhpet restore state issues (timers related)</li>
+
+	<li>Add partially support for suspending and resuming a Linux
+	guest</li>
+      </ul>
+
+      <p>Future tasks:</p>
+
+      <ul>
+	<li>Check if live migration can be implemented using the
+	FreeBSD's Copy-on-Write mechanism</li>
+
+	<li>Add live migration support by using EPT (Intel)</li>
+
+	<li>Add live migration support by using NPT (AMD)</li>
+
+	<li>Add suspend/resume support for nvme</li>
+
+	<li>Add suspend/resume support for virtio-console</li>
+
+	<li>Add suspend/resume support for virtio-scsi</li>
+
+	<li>Fix restore timers issues</li>
+
+	<li>Fix suspending bhyve - threads issues</li>
+
+	<li>Fix suspending bhyve - mutexes issues</li>
+
+	<li>Add suspend/resume support for Windows guests</li>
+      </ul>
+
+    </body>
+
+    <sponsor>
+      Matthew Grooms
+    </sponsor>
+
+    <sponsor>
+      iXsystems
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Building FreeBSD on non-FreeBSD hosts</title>
+
+    <contact>
+      <person>
+	<name>Alex Richardson</name>
+	<email>arichardson@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://wiki.FreeBSD.org/BuildingOnNonFreeBSD">Wiki</url>
+      <url href="https://github.com/arichardson/freebsd/tree/crossbuild-aug2018">GitHub project</url>
+    </links>
+
+    <body>
+      <p>Currently FreeBSD can only be built on a FreeBSD host.
+	However, most free
+	CI tools only allow building on Linux or macOS and
+	therefore can not be used
+	for building the FreeBSD base system. It is sometimes
+	useful to
+	cross-build FreeBSD for a remote machine or an emulator
+	even if the build
+	machine is not running FreeBSD.
+	The goal of this project is to allow building FreeBSD on
+	both Linux and macOS hosts
+	and in the future it may be extended to allow compiling on
+	a Windows host.
+	This work originates from the CHERI project and was
+	motivated by multiple cases of
+	people wanting to try out CheriBSD but not being able to
+	compile it since they did
+	not have a FreeBSD system available for compiling.
+	Once completed this project will also allow developers to
+	contribute to FreeBSD
+	even if they don't have access to a FreeBSD build system.</p>
+
+      <p>The current set of patches for this project can be found
+	on
+	<a
+	href="https://github.com/arichardson/freebsd/tree/crossbuild-aug2018">GitHub</a>.
+	With the current prototype it is possible to compile both
+	world and kernel for
+	architectures that use the clang compiler and for MIPS64,
+	which uses gcc. However, some options such as
+	LOCALES are
+	not supported yet and require further changes before the
+	bootstrap tools can be built
+	on Linux/macOS.</p>
+
+      <p>Some changes required for building on non-FreeBSD have
+	already been merged to
+	HEAD but there are still a rather large number of changes
+	that need review.</p>
+
+      <p>If you are interested in getting this into HEAD and would
+	like to help, please
+	try the current prototype and report any issues to
+	arichardson@FreeBSD.org.
+	If you can help with reviewing the changes please contact
+	arichardson@FreeBSD.org
+	to be added to any pending Phabricator reviews.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>ENA FreeBSD Driver Update</title>
+
+    <contact>
+      <person>
+	<name>Michał Krawczyk</name>
+	<email>mk@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 which is
+	used in the virtualised
+	environment of Amazon Web Services (AWS). It supports
+	multiple queues and can handle up to 25 Gb/s,
+	depending on the instance type on which it is
+	used.</p>
+
+      <p>Since last report, ENA versions v0.8.0 and v0.8.1 have
+	been released, which introduced
+	many bug fixes, new features, optimization, stability and
+	error recovery
+	improvements. The last is especially important on the AWS,
+	where the instances
+	have to be reliable as they may be running very sensitive
+	functions and the
+	down time of the VM should be reduced to minimum.</p>
+
+      <p>The v0.8.0 and v0.8.1 release patches included:</p>
+
+      <ul>
+	<li>Upgrade of the HAL to version v1.1.4.3</li>
+
+	<li>Improvement to the reset routine - the driver is now
+	triggering reset from
+	more fault points and is passing the reset reason to the
+	device, which can
+	perform the reset adequately to the encountered error.</li>
+
+	<li>Device statistics (like global Tx and Rx counters) are no
+	longer read directly from the device.
+	The only exception is Rx drops, which are still read using
+	the AENQ
+	descriptor.</li>
+
+	<li>The RX Out Of Order completion feature was added, which
+	enabled to cleanup the
+	RX descriptors out of order by keeping trace of all free
+	descriptors.</li>
+
+	<li>RX ring is now being monitored, to prevent the ring from
+	stalling.</li>
+
+	<li>Error handling paths were reworked and fixed.</li>
+
+	<li>Driver was covered with branch prediction statements, to
+	make the most
+	of this CPU feature in the hot paths.</li>
+
+	<li>Fix handling of the DF flag in the IP packets.</li>
+
+	<li>Add dynamic logging and reduce number of messages being
+	printed by the driver.</li>
+
+	<li>MTU configuration now is being verified using the device
+	capabilities instead
+	of a constant value.</li>
+
+	<li>Do not pass packet header length hint to the device,
+	because for the chained
+	mbufs it may be problematic to determine header length, if
+	the header is split
+	into multiple segments.</li>
+      </ul>
+
+    </body>
+
+    <sponsor>
+      Amazon.com Inc.
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>FreeBSD Graphics Team</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 is responsible for 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>There have been a lot of changes since the last report.
+	The most important one
+	is the change of driver distribution and updates. On
+	FreeBSD 11.2 and later
+	modern graphics drivers using the Linux KPI subsystem are
+	found in ports. These
+	give much improved support for Intel and AMD graphics
+	hardware, however, they
+	are currently only available for amd64.</p>
+
+      <p>The legacy drivers available in the FreeBSD base system
+	are also available in
+	the ports tree, since they cause issues with the new
+	drivers. They will remain
+	in tree for 11.2 and 12, but work is on-going to have them
+	removed for 13,
+	except for arm.</p>
+
+      <p>The easiest way to install the new drivers is to install
+	graphics/drm-kmod which
+	will install the correct driver depending on your
+	architecture and FreeBSD
+	version.</p>
+
+      <p>There have been changes to the ports as well. Most notably
+	is the changed
+	handling of OpenGL dependencies, which has moved to USES
+	instead of being
+	handled directly in bsd.port.mk. Other big infrastructure
+	changes is the move
+	from individual \*proto packages to xorgproto, and turning
+	that into a build
+	time dependency. Many thanks to portmgr for help with
+	exp-runs for these
+	changes.</p>
+
+      <p>There have been updates to applications and libraries as
+	needed.</p>
+
+      <p>On the project management side, there is ongoing work to
+	set up a more efficient
+	way of working, including bi-weekly conference calls to
+	discuss the current
+	works in progress. Notes from these conference calls will
+	be posted on the
+	mailing list.</p>
+
+      <p>Looking forward, the current major work in progress is to
+	update the graphics
+	driver to be on par with Linux 4.17. The code is merged,
+	but patching and bug
+	fixing is ongoing.</p>
+
+      <p>There is also work to port the VMware guest graphics
+	driver, vmwgfx, to FreeBSD
+	and to the Linux KPI, to get better graphics support in
+	VMware.</p>
+
+      <p>Lastly, on the driver side is to get the new graphics
+	drivers to work on i386 as
+	well. Experimental support for this exists in the code
+	repository, but is not
+	yet merged to the FreeBSD ports tree.</p>
+
+      <p>In userland, the biggest things happening is the update of
+	the input stack,
+	including libinput and supporting libraries.</p>
+
+      <p>Work is also ongoing on updating MESA libraries.</p>
+
+      <p>On the project management side, the most important tasks
+	is to continue to work
+	on the team, and how we work internally.</p>
+
+      <p>We are also working on setting up a list of requirements
+	for testing, so that we
+	can be reasonably assured that updates won't cause
+	regressions.</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>ifuncs</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Ed Maste</name>
+	<email>emaste@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Mark Johnston</name>
+	<email>markj@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Mateusz Guzik</name>
+	<email>mjg@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>An ifunc is a special construct in an ELF object, which
+	allows for
+	the selection of the implementation for the given symbol
+	at runtime,
+	when the ELF module gets the final relocations applied.
+	The selection
+	of which code to use is governed by the small piece of
+	user provided
+	code, attached to the symbol, the so called resolver
+	function.
+	Ifuncs provide a convenient way to select between
+	different
+	machine-specific implementations of the parts of the code,
+	without
+	the ugliness and unsafety of the alternative approach,
+	which is
+	runtime patching.</p>
+
+      <p>Ifuncs require support both from the static linker ld(1),
+	and from the
+	runtime linker for the corresponding execution
+	environment. On
+	FreeBSD, with the switch from the ancient GPLv2 licensed
+	BFD-based
+	ld(1) to either in-tree LLD or external modern BFD ld, the
+	use of
+	ifuncs become possible. Runtime linkers for ifunc support
+	exists for
+	the following environments:</p>
+
+      <ul>
+	<li>i386, amd64, and arm64 kernels</li>
+
+	<li>usermode dynamic linker ld-elf.so.1 on i386 and amd64</li>
+
+	<li>static binaries startup code for i386 and amd64</li>
+      </ul>
+
+      <p>
+	The use of ifuncs were previously applied for optimization
+	of the
+	following areas of the amd64 kernel:</p>
+
+      <ul>
+	<li>context switching code, instead of huge number of runtime
+	checks
+	(PTI vs non-PTI, PCID or not, is INVPCID instruction
+	supported for
+	PCID) now uses set of mode-specific routines, see
+	pmap_activate_sw(). Besides removing checks at runtime, it
+	also
+	makes the code much more cleanly structured and readable.</li>
+      </ul>
+
+      <ul>
+	<li>TLB and cache flush implementation.</li>
+      </ul>
+
+      <ul>
+	<li>memcpy/memmove, copyin/copyout variants selection for ERMS
+	and SMAP.</li>
+      </ul>
+
+      <ul>
+	<li>FPU state save and restore, depending on the support for
+	AVX or not,
+	this is also used on i386.</li>
+      </ul>
+
+      <p>
+	For amd64 userspace, we currently use ifunc for
+	optimization of the
+	architecture dependent TLS base set and get functions.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Intel Work on Core Enabling and Security</title>
+
+    <contact>
+      <person>
+	<name>Ben Widawsky</name>
+	<email>bwidawsk@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>A new team has been formed within Intel to help with side
+	channel security
+	mitigations as well as core enabling. They are evaluating
+	work from all areas
+	except networking. The team is currently focusing on two
+	areas:</p>
+
+      <ol><li>Power Management improvements</li>
+	<li>NVDIMM namespace support</li></ol>
+
+      <p>The ultimate goal of the power management work is to get
+	runtime power
+	management to hit "opportunistic idle". What this means is
+	when devices are
+	idle, the OS will power them down, and when everything
+	goes idle certain SoCs
+	will allow you to hit very low power states across the
+	platform. FreeBSD
+	currently doesn't have any notion of runtime power
+	management, and many devices
+	don't properly implement suspend and resume. In addition,
+	some preliminary work
+	is in process as it was thought to help when eventually
+	enabling opportunistic
+	idle. That preliminary work has been happening and is now
+	up for review:</p>
+
+      <ul>
+	<li><a
+	href="https://reviews.FreeBSD.org/D17675">https://reviews.FreeBSD.org/D17675</a></li>
+
+	<li><a
+	href="https://reviews.FreeBSD.org/D17676">https://reviews.FreeBSD.org/D17676</a></li>
+      </ul>
+
+      <p>
+	NVDIMM namespace support has also been put up for review.
+	ACPI spec defines
+	namespaces as a way of partitioning the device into
+	separate labels. The current
+	work will integrate with geom(4). How these are used is
+	application dependent.
+	This work is up for review as well: <a
+	href="https://reviews.FreeBSD.org/D17619">https://reviews.FreeBSD.org/D17619</a></p>
+
+      <p>The team has additionally taken on smaller tasks like
+	porting turbostat(8),
+	working on git svn init scripts, some small modifications
+	to acpi tooling, and
+	an effort to create a port PMDK.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>LLVM 7.0 - Sanitizers support improvements / Static code analysis</title>
+
+    <contact>
+      <person>
+	<name>David Carlier</name>
+	<email>devnexen@gmail.com</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html">Release notes</url>
+    </links>
+
+    <body>
+      <p>In order to increase the FreeBSD tooling to uncover
+	code bugs in the userland, further compiler-rt components
+	support and static code analysis improvements had been
+	added
+	since the last 6.0 version.</p>
+
+      <p>Starting with the sanitizers, Memory Sanitizer (for amd64)
+	mainly to
+	detect unitialized pointers. There is also a simple W^X
+	paging
+	requests detection available from most of sanitizers.</p>
+
+      <p>Also libFuzzer support finally had been possible.
+	It allows code to be tested with random values from corpus
+	inputs.
+	Mutation and combination algorithms of those random inputs
+	can be overwritten. Can also be used in addition to ubsan,
+	asan, msan and so on.</p>
+
+      <p>At last, the X-Ray instrumentation feature is also
+	supported.
+	It is mainly about performance profiling purposes for a
+	reasonable performance runtime cost.</p>
+
+      <p>In the static code analysis department, reliable strlcpy
+	(unfortunately strlcat
+	did not get merged in due time for the release) wrong
+	usage
+	cases are now covered and W^X code detection tooling had
+	been added.</p>
+
+      <p>At the moment, this 7.0 version is imported by Dimitry
+	Andric, within
+	its own git branch available only for FreeBSD after 12
+	releases.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Boot Loader</title>
+
+    <contact>
+      <person>
+	<name>Warner Losh</name>
+	<email>imp@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Kyle Evans</name>
+	<email>kevans@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Toomas Soome</name>
+	<email>tsoome@Freebsd.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The FreeBSD boot loader lives in src/stand (prior releases
+	had it in
+	sys/boot and lib/libstand). It covers all the code that
+	the project
+	provides that interacts with the hardware before the
+	kernel starts.</p>
+
+      <p>The LUA interpreter added earlier in 2018 was made default
+	in 2018Q3.
+	Due to undiagnosed booting issues, the LUA interpreter has
+	been
+	disabled on sparc64 and all powerpc. The LUA interpreter
+	is scheduled
+	to replace the FORTH interpreter entirely in FreeBSD 13,
+	although the
+	FORTH interpreter will remain available as a build option
+	in FreeBSD
+	12. The plans are not to remove the FORTH loader for about
+	a year
+	after 12.0 release, or approximately January 2020.
+	Platforms not
+	currently working with the LUA interpreter
+	have until that date to resolve the issues.</p>
+
+      <p>At this point, the LUA scripts implement everything that
+	the FORTH scripts
+	did. Where there was ambiguity in the spec, or where the
+	FORTH scripts
+	were more forgiving than was strictly documented, every
+	effort has
+	been made to improve the documentation and follow the old
+	FORTH
+	behavior, or document the new behavior where the old
+	behavior was
+	clearly a bug.</p>
+
+      <p>It's anticipated that no further changes to the FORTH
+	loader or the
+	FORTH scripts will happen. They are quite mature and
+	bullet proof at
+	this point and it's unlikely that an undiscovered bug will
+	need to be
+	fixed before retirement.</p>
+
+      <p>Other work in progress includes Toomas Soome's port to
+	OpenIndiana. In
+	addition to porting, he's enhanced the code in a number of
+	ways (both
+	in the block layer, and UEFI). Many of his improvements
+	have been
+	committed to FreeBSD, though a few remain and hopefully
+	will be
+	entering the tree soon after the freeze lifts.</p>
+
+      <p>UEFI booting has been greatly enhanced. There are still
+	some
+	machines that have issues with the default BootXXXX
+	variables or
+	something else in the environment that are being
+	investigated. We hope
+	to understand the problems well enough to provide a fix
+	for FreeBSD
+	12.0.</p>
+
+      <p>Ian Lepore has reworked the GELI support so that it is
+	architecture independent and can be
+	used on any architecture we support.</p>
+
+      <p>There are also efforts underway to support booting signed
+	images, improved
+	crypto booting options, and implement Multiboot 2.0
+	support.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Usermode mapping of PCI BARs</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Modern PCI(e) devices typically define memory-mapped BARs
+	(Base Address Registers) to make a memory region available
+	to the device.
+	Each BAR
+	has a separate page-aligned boundary and memory region
+	associated with it.
+	This is enforced by the need
+	of hypervisors to provide the pass-through using VT-d,
+	which operates
+	with memory and has the granularity of one page for access
+	control.
+	As is, it
+	also means that the BARs have a suitable configuration for
+	providing
+	access to usermode, controlling access by the normal page
+	tables.</p>
+
+      <p>Linux already gives a way for userspace mapping of BARs
+	using sysfs.</p>
+
+      <p>Of course, if a userspace program has enough privileges,
+	it can read a BAR,
+	determine the physical address of the mapping as seen by
+	CPU, and use
+	mem(4) (aka /dev/mem) to mmap() that region of memory.
+	This is very cumbersome, and leaves many unresolved
+	issues.
+	For example, a BAR might be not activated, which would
+	require
+	involvement of the IOMMU on some architectures. Also this
+	rude approach
+	makes it very hard to create mappings with the correct
+	caching
+	attributes.</p>
+
+      <p>The FreeBSD pci(4) driver was enhanced to support such
+	mappings, and pciconf(8) utility was extended to use the
+	new support.
+	See pci(4)
+	for PCIOCBARMMAP ioctl(2) request description for details,
+	and
+	pciconf(8) for the -D switch.</p>
+
+      <p>TODO: automatically activate the BAR on mapping, this is
+	not done yet.
+	There is a problem with avoiding the resource conflicts on
+	possible future attachmens of the kernel driver.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+    <sponsor>
+      Mellanox Technologies
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Device Mode USB</title>
+
+    <contact>
+      <person>
+	<name>Edward Tomasz Napierala</name>
+	<email>trasz@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/usb-device-mode.html">Handbook chapter</url>
+    </links>
+
+    <body>
+      <p>Many embedded boards include hardware which supports
+	device
+	side USB - the ability for the board to present itself to
+	another
+	system as a USB drive, network adapter, or a virtual
+	serial port.
+	The FreeBSD USB stack has supported this functionality for
+	quite some
+	time, but it has not been used to its fullest extent.</p>
+
+      <p>The goal of this project was to fix that - to document the
+	functionality, possibly fix some bugs, and to make it easy
+	to use, automating it as much as possible.</p>
+
+      <p>Starting with FreeBSD 12.0, this functionality is enabled
+	out of the box. This means you can connect your BeagleBone
+	Black's (using its USB client socket) or a Raspberry Pi 0
+	(using the On-The-Go (OTG) port) to your laptop, and
+	you'll get a virtual
+	USB serial port, which serves as a system console, with
+	getty(8)
+	waiting for you to log in. This means you no longer need
+	to
+	look for a keyboard and a screen, or mess with the console
+	cables just to configure your system. You can also switch
+	it to provide network interface, or present itself as a
+	USB
+	drive - it's all documented in the FreeBSD Handbook.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Performance improvements</title>
+
+    <contact>
+      <person>
+	<name>Matthew Macy</name>
+	<email>mmacy@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>FreeBSD 12 saw the introduction of a number of performance
+	improvements:</p>
+
+      <ul>
+	<li>The introduction of the new synchronization primitive
+	epoch(9) to
+	replace the use of reader locks for providing existence
+	guarantees
+	for data structures.</li>
+
+	<li>epoch(9) was used to provide an 85+% reduction in the
+	overhead of
+	pcb lookup in high core count systems.</li>
+
+	<li>epoch(9) was used to provide an 85+% reduction in UDP send
+	overhead
+	on high core count systems. See the link for a bit more
+	detail:
+	<a
+	href="http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-liveness-guarantees">http://scalebsd.org/blog/2018/06/16/UDP-and-epoch-for-liveness-guarantees</a></li>
+	<li>System call overhead is now half that of FreeBSD 11.</li>
+
+	<li>UNIX sockets now scale near linearly (previously maxed out
+	at 3-4 threads).</li>
+
+	<li>The NUMA work has lead to a 20x-80x improvement in the
+	scalability
+	of page fault handling.</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>Armada 38x FreeBSD support</title>
+
+    <contact>
+      <person>
+	<name>Marcin Wojtas</name>
+	<email>mw@semihalf.com</email>
+      </person>
+      <person>
+	<name>Patryk Duda</name>
+	<email>pdk@semihalf.com</email>
+      </person>
+      <person>
+	<name>Rafał Kozik</name>
+	<email>rk@semihalf.com</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://www.marvell.com/documents/egrkpyqzpoebxblyeept/">PRODUCT BRIEF</url>
+    </links>
+
+    <body>
+      <p>The Marvell Armada 38x is a very poplular ARMv7-based dual
+	core SoC.
+	Thanks to the multiple low and high speed interfaces
+	the platform is used in a wide range of products, such
+	as Network-Attached Storage (NAS), Wi-Fi Access Point
+	(WAP) and others.</p>
+
+      <p>Since last report, remaining Armada 38x support was
+	integrated to HEAD, which can now compile with the
+	armv7
+	GENERIC config and use unmodified sys/gnu/dts device
+	trees. The details are as follows:</p>
+
+      <ul>
+	<li>GENERIC config</li>
+
+	<li>Introduce a vast rework of the sys/arm/mv directory for
+	arm and armv7 platforms.</li>
+
+	<li>Enable PLATFORM support for Marvell ARMv7 SoCs, which can
+	now can boot with GENERIC kernel.</li>
+
+	<li>Base on dynamic detection of SoC type and device tree
+	instead of using ifdefs
+	and enable more flexible environment for maintaining
+	Marvell platforms.</li>
+
+	<li>sys/gnu/dts device trees</li>
+
+	<li>Improve platform code and the drivers (e.g. CESA, PCIE,
+	GPIO) to properly work with original
+	Linux device trees.</li>
+
+	<li>GPIO</li>
+
+	<li>Add multiple fixes and improvements to the
+	sys/arm/mv/gpio.c</li>
+
+	<li>Rework driver to properly integrate with HEAD GPIO
+	frameworks (main and gpioled)</li>
+
+	<li>Enable support for both old and Linux GPIO device tree
+	bindings, so that multiple controllers
+	can be used.</li>
+      </ul>
+
+    </body>
+
+    <sponsor>
+      Stormshield
+    </sponsor>
+
+    <sponsor>
+      Semihalf
+    </sponsor>
+
+  </project>
+
+  <project cat='arch'>
+    <title>PINE64-LTS Image</title>
+
+    <contact>
+      <person>
+	<name>Emmanuel Vadot</name>
+	<email>manu@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>We now produce an image for the PINE64-LTS.
+	This image works on the PINE64-LTS and the Sopine with
+	Baseboard.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>PocketBeagle Support</title>
+
+    <contact>
+      <person>
+	<name>Emmanuel Vadot</name>
+	<email>manu@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Tom Jones</name>
+	<email>thj@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://www.beagleboard.org/pocket">Pocket Beagle</url>
+    </links>
+
+    <body>
+      <p>The Pocket Beagle is the latest member of the BeagleBoard
+	family.
+	Support for it was added and the Beaglebone image can be
+	used on it directly.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>Allwinner SoC Support</title>
+
+    <contact>
+      <person>
+	<name>Emmanuel Vadot</name>
+	<email>manu@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <ul>
+	<li>SPI driver added for A64 SoC</li>
+
+	<li>Thermal driver added/fixed for A64/H3/H5 SoCs</li>
+
+	<li>Lot of bugs where fixed in the mmc driver, stability
+	should be better</li>
+
+	<li>New driver for AXXP803 which is the power chip companion
+	of the A64 SoC</li>
+
+	<li>Add overlays to use another timer controller as the
+	default one in A64 if faulty
+	These overlay is enabled in the PINE64/LTS images by
+	default</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>ARMv6 and ARMv7 image now use EFI loader</title>
+
+    <contact>
+      <person>
+	<name>Emmanuel Vadot</name>
+	<email>manu@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Instead of using the ubldr version of the loader which
+	uses the U-Boot
+	API, all images now use loader.efi as their primary
+	FreeBSD loader.
+	This allow us to have a common boot path for all arm and
+	arm64 images.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>DTS Update</title>
+
+    <contact>
+      <person>
+	<name>Emmanuel Vadot</name>
+	<email>manu@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>DTS files (Device Tree Sources) were updated to be on par
+	with Linux 4.18 for
+	the 12.0 release.</p>
+
+      <p>The DTS are now compiled for some arm64 boards as the one
+	present in U-Boot are
+	now always up-to-date.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>RPI Firmware/DTB/U-Boot Update</title>
+
+    <contact>
+      <person>
+	<name>Emmanuel Vadot</name>
+	<email>manu@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>U-Boot mailing list</name>
+	<email>uboot@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The RaspberryPi firmware loads the DTB from the FAT
+	partition based on
+	the model. U-Boot now uses this DTB and passes it to the
+	FreeBSD loader/kernel
+	instead of using the DTS embedded in U-Boot.
+	This allow the FreeBSD Kernel to use the RaspberryPi
+	Foundation provided DTB overlays to enable
+	HATs.
+	The overlays can be obtained by installing the
+	rpi-firmware package.</p>
+
+      <p>A new U-Boot port for the W variant of the RPI0 was
+	committed as
+	u-boot-rpi-0-w. Some experiments started by Edward Tomasz
+	Napierala
+	(trasz@) have shown that we could possibly produce a
+	generic image
+	for all armv6 RPI (RPI-B, RPI0 and RPI0W).</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>FreeBSD on PowerNV (ppc64)</title>
+
+    <contact>
+      <person>
+	<name>Patryk Duda</name>
+	<email>pdk@semihalf.com</email>
+      </person>
+      <person>
+	<name>Wojciech Macek</name>
+	<email>wma@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Michal Stanek</name>
+	<email>mst@semihalf.com</email>
+      </person>
+      <person>
+	<name>Nathan Whitehorn</name>
+	<email>nw@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Semihalf is happy to announce that FreeBSD is now running
+	on IBM POWER8. This project is a continuation of
+	work done by Nathan Whitehorn who provided basic
+	support for a PowerNV emulator.</p>
+
+      <p>The IBM POWER8 family of CPUs offers superior performance
+	compared to previous Power series. It provides
+	complete NUMA support with up to 192 cores in a
+	two socket system (up to 8 threads per core). All
+	IO communication is handled by integrated PCIe
+	interface equipped with multiple IOMMU engines.</p>
+
+      <p>The support for POWER8 system running FreeBSD in
+	Non-Virtualized environment contains:</p>
+
+      <ul>
+	<li>Generic driver for OPAL hypervisor</li>
+
+	<li>kboot loader modifications to allow Little-Endian loader
+	to load a Big-Endian kernel ELF</li>
+
+	<li>skiboot update for ELF-parser allowing it to understand
+	FreeBSD kernel file format</li>
+
+	<li>Basic support for PowerNV architecture, including modes of
+	operation, MMU, interrupt controller</li>
+
+	<li>SMP operation (tested with 128 CPU configuration)</li>
+
+	<li>PHB subsystem driver, including IOMMU mapping for external
+	buses</li>
+
+	<li>PCIe host controller driver</li>
+
+	<li>USB-3.0 XHCI driver</li>
+
+	<li>Reworked drivers to be Big-Endian compatible:</li>
+
+	<li>Chelsio cxgbe(4) 10/25G network adapter</li>
+
+	<li>NVMe SSD drive</li>
+      </ul>
+
+      <p>
+	All work has been merged into HEAD and will be included in
+	FreeBSD 12.0-RELEASE.</p>
+
+      <p>Sponsors: IBM, FreeBSD Foundation, QCM Technologies,
+	Semihalf, Limelight Networks.</p>
+
+      <p>The project is kindly initiated and supported by Limelight
+	Networks (Kevin Bowling).</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>FreeBSD on POWER9</title>
+
+    <contact>
+      <person>
+	<name>Matthew Macy</name>
+	<email>mmacy@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Once Justin Hibbits largely stabilized the powerpc64 port
+	on the POWER9
+	based Talos II I decided to procure one. I've been slowly
+	working towards
+	taking powerpc64 to parity with amd64. I've been working
+	in an out of tree
+	GitHub project - in part to eliminate the need to continue
+	to support the 11
+	year old in tree gcc4.</p>
+
+      <p>Progress so far:</p>
+
+      <ul>
+	<li>Adapted lock_delay to use POWER's SMT scheduling hints
+	rather than
+	using the yield hint from an older ISA</li>
+
+	<li>Added ifunc support</li>
+
+	<li>Ported the amd64 pmap so FreeBSD can use POWER9's new
+	radix tree
+	page tables. This will give us superpages mostly for free.</li>
+
+	<li>Reduced the overhead of copyinout primitives for radix.</li>
+
+	<li>Converted the copyinout primitives to ifuncs to switch
+	between the
+	old and the new at initialization time.</li>
+
+	<li>Converted pmap to use ifuncs to eliminate the overhead of
+	kobj dispatch.</li>
+
+	<li>Hot patch out trap handling paths only needed by the older
+	hashed page
+	table support.</li>
+      </ul>
+
+      <p>
+	Work in Progress:</p>
+
+      <ul>
+	<li>NMI semantics: NMIs need to be emulated by only soft
+	disabling interrupts,
+	disabling interrupts blocks all interrupts except machine
+	check exceptions
+	and system resets.</li>
+
+	<li>Superpage support: Superpages work in the functional
+	simulator running SMT4
+	but currently crash on real hardware due to incomplete
+	page walk cache /
+	TLB invalidation.</li>
+
+	<li>Kernel minidump - with radix MMU enabled minidump support
+	was a fairly
+	straightforward port but time needs to be spent on test /
+	debug.</li>
+
+	<li>EARLY_AP_STARTUP - preliminary patches exist, but this is
+	more work on !x86
+	architectures due to IPI setup not being tied to the CPU
+	code.</li>
+      </ul>
+
+      <p>
+	A list of the other items needed to achieve kernel feature
+	parity with a
+	(wishful) list of milestones can be found at:
+	<a
+	href="https://github.com/POWER9BSD/freebsd/projects/1">https://github.com/POWER9BSD/freebsd/projects/1</a></p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <title>FreeBSD on RISC-V</title>
+
+    <contact>
+      <person>
+	<name>Ruslan Bukin</name>
+	<email>br@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>FreeBSD/RISC-V has been one of the actively supported
+	projects during the past year.</p>
+
+      <p>On a compiler front we have upstreamed FreeBSD
+	OS-dependent bits for GNU toolchain. It was
+	updated to GCC 8.1 and Binutils 2.30. FreeBSD
+	packages are available.</p>
+
+      <p>FreeBSD Testsuite and required dependencies were
+	successfully built for RISC-V and we did a test
+	run: 152 tests failed out of 5186, which
+	demonstrates a very good result for initial run
+	and reveals areas to work on.</p>
+
+      <p>We have added support for compressed ISA extension to KDB
+	debugger and DTrace FBT provider enabling
+	C-compressed kernel and userland by default. The
+	output of disassembling instructions in KDB is
+	looking similar to objdump.</p>
+
+      <p>QEMU has updated to latest privilege spec allowing us to
+	bring up FreeBSD on it. The emulation is quite
+	fast: it takes one second only to boot FreeBSD to
+	single-user mode in QEMU: <a
+	href="https://www.youtube.com/watch?v=FnWpRBaWF18">https://www.youtube.com/watch?v=FnWpRBaWF18</a></p>
+
+      <p>Platform-Level Interrupt Controller (PLIC) driver was
+	added. Interrupt support was converted to INTRNG.
+	PLIC is used in QEMU for virtio network and block devices.
+	With these changes, a full FreeBSD distribution
+	can now be booted in QEMU.</p>
+
+      <p>Network virtualization support (VIMAGE) was fixed and
+	enabled by default now.</p>
+
+      <p>In order to support RocketChip and derivatives we had to
+	work on A(accessed), D(dirty) PTE (page table
+	entry) bits management.
+	We have successfully tested this on a lowRISC board and it
+	is booting to multiuser just fine. lowRISC UART
+	driver was added.</p>
+
+      <p>Superuser-User-Modify (SUM) bit in status register is now
+	used: kernel can access userspace only within
+	certain functions that explicitly handle crossing
+	user/kernel boundary.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>KDE on FreeBSD</title>
+
+    <contact>
+      <person>
+	<name>Adriaan de Groot</name>
+	<email>adridg@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Tobias C. Berner</name>
+	<email>tcberner@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://FreeBSD.kde.org/">KDE FreeBSD</url>
+    </links>
+
+    <body>
+      <p>KDE FreeBSD is responsible for the ports of the Plasma5
+	and KDE4 desktops, and
+	all associated applications. Further we also manage the
+	Qt4 and Qt5 ports, as
+	well as CMake.</p>
+
+      <p>We also care for the FreeBSD builders for KDE's upstream
+	CI on build.kde.org.</p>
+
+      <p>Since the last status report a lot of things have changed.
+	First and foremost,
+	the Plasma5 Desktop and the Qt5 based KDE Applications
+	have finally made their
+	way into the official ports tree after lingering for
+	multiple years in our
+	development repository.</p>
+
+      <p>Secondly KDE4 has been marked deprecated and will be
+	removed at the end of the
+	year. With Qt4 following no later than the next year (due
+	to the exponentially
+	increasing burden of maintenance).</p>
+
+      <p>On a more technical side, bsd.qt.mk has been replaced by
+	qt.mk and qt-dist.mk.
+	The porter's handbook is being updated (with thanks to
+	Tobias Kortkamp).</p>
+
+      <p>Further we have been keeping CMake and Qt5 and almost
+	every other port under our
+	control up to date. SDDM has been updated to the
+	next-to-latest release with
+	backported security fixes.</p>
+
+      <p>One big issue we have is www/qt5-webengine, which requires
+	too much time to keep
+	up to date, as the underlying chromium is in need of many
+	patches, which change
+	with every release. Another upcoming issue is the way in
+	which FreeBSD's libinput
+	lags behind. This blocks future updates to KDE Plasma as
+	well as Wayland
+	improvements. Thankfully x11@ is looking at this issue
+	already, so it should be
+	fixed soon -- for the meantime people who want to give the
+	latest KDE Plasma
+	Desktop a try can use the appropriate branch from our
+	GitHub.</p>
+
+      <p>People who are willing to contribute can find us on
+	#kde-freebsd on freenode,
+	the kde@FreeBSD.org mailing list. Further, we accept
+	pull-requests and
+	contributions on github.com/freebsd/freebsd-ports-kde.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>Puppet</title>
+
+    <contact>
+      <person>
+	<name>Puppet Team</name>
+	<email>puppet@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://puppetcommunity.slack.com/messages/C6CK0UGB1/">PuppetLab's FreeBSD slack channel</url>
+      <url href="https://www.bsdcan.org/2018/schedule/events/930.en.html">BSDCan 2018: IT automation with Puppet</url>
+    </links>
+
+    <body>
+      <p>Since our last status report last year, the puppet@ team
+	regularly updated the
+	Puppet ports to catch on upstream releases. We have also
+	held a Puppet talk at
+	BSDCan.</p>
+
+      <p>More recently, Puppet 6 was released, and a bunch of new
+	ports appeared in the
+	FreeBSD ports tree: sysutils/puppet6,
+	sysutils/puppetserver6,
+	databases/puppetdb6 being (obviously) the main ones. In
+	this update, the Puppet
+	language has not been heavily modified. As a consequence,
+	upgrading from Puppet
+	5 to Puppet 6 is an easy task compared to the experience
+	you may have
+	encountered from previous major version bumps. If you are
+	still using Puppet 4,
+	we recommend to schedule an upgrade soon: Puppet 4 is
+	expected to be EOL by the
+	end of 2018.</p>
+
+      <p>Because distributing Marionette Collective modules via
+	Puppet is more efficient
+	than using packages, the
+	sysutils/mcollective-\*-{agent,client} ports have
+	been
+	deprecated. Marionette Collective itself being phased out
+	by PuppetLabs, the
+	sysutils/mcollective port is expected to be deprecated at
+	some point in the
+	future, but we plan to keep it until an alternative is
+	available. This
+	alternative, called Choria, is in active development by
+	R.I.Pienaar the
+	original author of Marionette Collective. We are actively
+	working with him to
+	support FreeBSD out of the box, and will commit
+	sysutils/choria to the tree as
+	soon as it is considered a drop-in replacement for
+	Marionette Collective.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>scarab: CLI tool for Bugzilla-related workflows</title>
+
+    <contact>
+      <person>
+	<name>Oleksandr Tymoshenko</name>
+	<email>gonzo@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://github.com/gonzoua/scarab">GitHub repo</url>
+    </links>
+
+    <body>
+      <p>scarab is a CLI tool that makes some of Bugzilla
+	functionality
+	available from the command line. Normally users interact
+	with the
+	<a
+	href="https://bugs.FreeBSD.org/bugzilla/">bugtracker</a>
+	using a web browser
+	but for certain workflows, Web UI may be more of an
+	obstacle
+	than help requiring to perform more steps compared to CLI
+	tool.</p>
+
+      <p>Bugzilla provides XML-RPC interfaces that can be used for
+	automation/integration and there are several CLI tools
+	like
+	<a href="https://github.com/williamh/pybugz">pybugz</a>
+	that can be used
+	with bugs.FreeBSD.org as-is. They are generic
+	one-size-fits-all
+	tools which mean they can do a lot of thing at the cost of
+	more complex CLI.</p>
+
+      <p>scarab was created to be more specialized and less complex
+	with following
+	principles in mind:</p>
+
+      <ul>
+	<li>Be an auxiliary tool, not a replacement for the web UI</li>
+
+	<li>Move complexity to a configuration file, keep arguments as
+	simple as possible</li>
+
+	<li>Optimize for most common/tedious tasks</li>
+      </ul>
+
+      <p>
+	Based on my experience with Bugzilla following tasks were
+	identified as
+	candidates for inclusion in the first release of the tool:</p>
+
+      <ul>
+	<li>Downloading attachment on host machine and copying it to
+	devbox</li>
+
+	<li>Creating a file on the devbox and copying it to a host
+	machine to be attached through Web UI</li>
+
+	<li>Creating PRs with common fields' values</li>
+      </ul>
+
+      <p>
+	First two operations were implemented as <tt>files</tt>,
+	<tt>fetch</tt>, <tt>fetchall</tt>, <tt>attach</tt>
+	commands of the tool.</p>
+
+      <p>The third operation was implemented by introducing PR
+	templates, set of
+	predefined field/value pairs, that can be combined
+	run-time to provide higher
+	flexibility. More information and usage examples can be
+	found in the
+	<a
+	href="https://github.com/gonzoua/scarab/blob/master/examples/scarabrc">config
+	file example</a></p>
+
+    </body>
+
+  </project>
+
+  <project cat='doc'>
+    <title>Quarterly Reports</title>
+
+    <contact>
+      <person>
+	<name>Edward Tomasz Napierała</name>
+	<email>trasz@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Mateusz Piotrowski</name>
+	<email>0mp@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The Quarterly Reports have been resurrected after almost a
+	year long hiatus.
+	The old workflow, which consisted of users submitting
+	XML-formatted entries,
+	which would then get hand-assembled into DocBook, was
+	replaced with a new
+	one, using Markdown instead. The XML submission form was
+	replaced with
+	GitHub Pull Requests. This should make submissions and
+	editing much easier
+	and user-friendly.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='doc'>
+    <title>Cleaning up the Wiki</title>
+
+    <contact>
+      <person>
+	<name></name>
+	<email>wiki-admin@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://wiki.FreeBSD.org/WikiFixitGroup/">Wiki Fixit Group Website</url>
+      <url href="irc://freebsd-wiki@irc.freenode.net">IRC channel</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD Wiki used to be a scratch pad for the FreeBSD
+	developers to
+	organize projects, store notes and publish articles that
+	were about to be added
+	to the handbook. Recently, however, the FreeBSD wiki
+	started to attract more
+	and more people from the wider FreeBSD community, which
+	resulted in a change of
+	the character of the wiki.</p>
+
+      <p>As a result we decided to discuss the future of the tools
+	we want to use for
+	documentation in FreeBSD (one of such discussions was held
+	during BSDCam 2018,
+	you may see some notes
+	<a
+	href="https://wiki.FreeBSD.org/DevSummit/201808/DeveloperTools">here</a>).
+	The general
+	conclusion is that wiki is a great tool for what it was
+	meant for: organizing
+	projects and notes in the community of developers. We
+	should not move all our
+	documentation (especially handbooks) to Wiki as the
+	quality and maintainability
+	would suffer. On the other hand, the current workflow of
+	submitting
+	documentation patches, which involves checking out the doc
+	tree and patching
+	XML files is not ideal for many end users. This is why we
+	are trying to approach the problem from various
+	directions:</p>
+
+      <ol><li>The wiki is being cleaned up of old content. We are
+	trying to define a clear
+	hierarchy of subpages and categories to make navigating
+	the wiki easier.</li>
+      <li>Some articles from the wiki are going to be migrated to
+	either the doc tree
+	or manual pages.</li></ol>
+
+    </body>
+
+  </project>
+
+  <project cat='third'>
+    <title>HardenedBSD 2018Q3 Update</title>
+
+    <contact>
+      <person>
+	<name>Shawn Webb</name>
+	<email>shawn.webb@hardenedbsd.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Our last report was
+	<a
+	href="https://www.FreeBSD.org/news/status/report-2017-04-2017-06.html#HardenedBSD">June
+	2017</a>.
+	A lot has transpired since then. In this status report, we
+	will
+	attempt to briefly cover all the progress we've made,
+	including the
+	few commits that made it upstream to FreeBSD.</p>
+
+      <p>On 01 Jul 2018, we switched back to
+	<a
+	href="https://hardenedbsd.org/article/shawn-webb/2018-04-30/hardenedbsd-switching-back-openssl">OpenSSL</a>
+	as the crypto library provider in base. We did this
+	because we lack
+	the resources and the documentation for properly
+	supporting LibreSSL
+	in base. We still maintain LibreSSL in base; however,
+	OpenSSL is
+	simply the default crypto library (aka,
+	<tt>WITHOUT_LIBRESSL</tt> is the
+	default). We look forward to building a development
+	community around
+	LibreSSL in HardenedBSD such that we can re-enable
+	LibreSSL by
+	default, providing enhanced security for our users through
+	the
+	rejection of software monocultures.</p>
+
+      <p>Cross-DSO Control Flow Integrity (Cross-DSO CFI) is an
+	exploit
+	mitigation from llvm that provides forward-edge
+	protections across
+	shared library and application boundaries. With
+	HardenedBSD 12-STABLE,
+	we launched non-Cross-DSO CFI support in base. Meaning,
+	CFI is only
+	applied to applications and not shared libraries. Along
+	with
+	SafeStack, which provides backward-edge protections,
+	Cross-DSO CFI
+	requires both ASLR and W^X for effectiveness as they store
+	crucial
+	metadata needing protection. HardenedBSD expertly,
+	efficiently, and
+	robustly fulfill those requirements through its PaX ASLR
+	and PaX
+	NOEXEC implementations.</p>
+
+      <p>Over the past two years, we have slowly worked on
+	Cross-DSO CFI
+	support in HardenedBSD. In mid-2018, we made enough
+	progress that we
+	could publish an alpha
+	<a
+	href="https://hardenedbsd.org/article/shawn-webb/2018-07-16/preliminary-call-testing-cross-dso-cfi">Call-For-Testing
+	(CFT)</a>.
+	We need to integrate the Cross-DSO CFI support with the
+	RTLD such that
+	function pointers resolved through
+	<tt>dlopen(3)</tt>/`dlsym(3)` work properly
+	with the cfi-icall scheme. We also need to perform
+	experimental
+	package builds, find breakages, and fix those breakages.
+	We hope to
+	officially debut Cross-DSO CFI in the latter half of 2019
+	with the
+	possibility of pushing back to 2020. HardenedBSD remains
+	the first and
+	only enterprise operating system to use CFI across the
+	base set of
+	applications.</p>
+
+      <p>On 20 Aug 2018, we launched a new tool called
+	<tt>hbsdcontrol(8)</tt> to
+	toggle exploit mitigations on a per-application basis.
+	<tt>hbsdcontrol(8)</tt> uses filesystem extended
+	attributes and is the
+	preferred method for exploit mitigation toggling for those
+	filesystem
+	that support extended attributes (UFS, ZFS). Our original
+	utility,
+	<tt>secadm</tt>, should be used with filesystems that do
+	not support extended
+	attributes (NFS).</p>
+
+      <p>In <a
+	href="https://hardenedbsd.org/article/shawn-webb/2018-09-17/announcing-hardenedbsd-foundation">September
+	2018</a>,
+	the HardenedBSD Foundation Corp became a 501(c)(3)
+	tax-exempt,
+	not-for-profit organization in the USA. This means that
+	donations by
+	US persons are eligible for tax deductions. The creation
+	of the
+	HardenedBSD Foundation will ensure that HardenedBSD
+	remains successful
+	long-term. We look forward to working with the BSD
+	community to
+	provide an open source, clean-room reimplementation of the
+	grsecurity
+	patchset based on publicly-available documentation.</p>
+
+      <p>We assisted Kyle Evans with the new <tt>bectl(8)</tt>
+	utility, primarily
+	enhancing jail support and fixing regressions. We are
+	grateful for
+	Kyle Evans' assistance in landing the enhancements
+	upstream in FreeBSD
+	and his overall responsiveness and helpfulness.</p>
+
+      <p>Relevant commits for the <tt>bectl(8)</tt> are:</p>
+
+      <ul>
+	<li><a
+	href="https://svnweb.FreeBSD.org/base?view=revision&amp;revision=339047">r339047</a></li>
+
+	<li><a
+	href="https://svnweb.FreeBSD.org/base?view=revision&amp;revision=338221">r338221</a></li>
+
+	<li><a
+	href="https://svnweb.FreeBSD.org/base?view=revision&amp;revision=337993">r337993</a></li>
+
+	<li><a
+	href="https://svnweb.FreeBSD.org/base?view=revision&amp;revision=337947">r337947</a></li>
+      </ul>
+
+      <p>
+	We taught <tt>bhyve(8)</tt> how to live in a
+	<a href="https://reviews.FreeBSD.org/rS337023">jailed
+	environment</a>, allowing users to
+	jail the hypervisor. We hardened the virtual address space
+	of
+	<tt>bhyve(8)</tt> by using <a
+	href="https://reviews.FreeBSD.org/rS338511">guard
+	pages</a>.
+	This work made it upstream to FreeBSD. We are grateful to
+	those in
+	FreeBSD who provided insight to increase the quality and
+	efficiency
+	of our patches.</p>
+
+    </body>
+
+  </project>
+
+</report>