Page MenuHomeFreeBSD
Files F151673928

D22323.diff
No OneTemporary
Actions

D22323.diff
View Options

Index: head/en_US.ISO8859-1/htdocs/news/status/Makefile
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/Makefile
+++ head/en_US.ISO8859-1/htdocs/news/status/Makefile
@@ -84,6 +84,7 @@
XMLDOCS+= report-2018-09-2018-12
XMLDOCS+= report-2019-01-2019-03
XMLDOCS+= report-2019-04-2019-06
+XMLDOCS+= report-2019-07-2019-09
XSLT.DEFAULT= report.xsl
Index: head/en_US.ISO8859-1/htdocs/news/status/report-2019-07-2019-09.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2019-07-2019-09.xml
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2019-07-2019-09.xml
@@ -0,0 +1,3108 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
+ Status Report//EN"
+ "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
+
+<!-- $FreeBSD$ -->
+<!-- This file was generated with https://github.com/trasz/md2docbook -->
+<!--
+ Variables to replace:
+ %%START%% - report month start
+ %%STOP%% - report month end
+ %%YEAR%% - report year
+ %%NUM%% - report issue (first, second, third, fourth)
+ %%STARTNEXT%% - report month start
+ %%STOPNEXT%% - report month end
+ %%YEARNEXT%% - next report due year (if different than %%YEAR%%)
+ %%DUENEXT%% - next report due date (i.e., June 6)
+-->
+
+<report>
+ <date>
+ <month>07-09</month>
+
+ <year>2019</year>
+ </date>
+
+ <section>
+ <title>Introduction</title>
+<p>Here is the third quarterly status report for 2019.</p>
+
+<p>This quarter the reports team has been more active than usual thanks
+to a better organization: calls for reports and reminders have been
+sent regularly, reports have been reviewed and merged quickly (I would
+like to thank debdrup@ in particular for his reviewing work).</p>
+<p>Efficiency could still be improved with the help of our community.
+In particular, the quarterly team has found that many reports have
+arrived in the last days before the deadline or even after. I would
+like to invite the community to follow the guidelines below that
+can help us sending out the reports sooner.</p>
+<ul>
+<li>Send a first draft of your report when you receive the first call
+for reports (1 month before the deadline).</li>
+<li>Update your report, if needed, when you receive reminders: you will
+normaly receive two (2 weeks and 1 week before the deadline).</li>
+<li>If after the deadline you still have some more updates ask the team
+(either on IRC via #freebsd-wiki or send an email at monthly@) to
+wait for you if you feel that they are urgent, otherwise start
+putting them in a draft for the next quarter.</li></ul>
+
+<p>Starting from next quarter, all quarterly status reports will be
+prepared the last month of the quarter itself, instead of the first
+month after the quarter's end. This means that deadlines for
+submitting reports will be the 1st of January, April, July and
+October.</p>
+<p>Next quarter will then be a short one, covering the months of November
+and December only and the report will probably be out in mid January.</p>
+
+<p>-- Lorenzo Salvadore</p>
+ </section>
+
+ <category>
+ <name>team</name>
+
+ <description>&os; Team Reports</description>
+
+ <p>Entries from the various official and semi-official teams,
+ as found in the <a href="&enbase;/administration.html">Administration
+ Page</a>.</p>
+ </category>
+
+ <category>
+ <name>proj</name>
+
+ <description>Projects</description>
+
+ <p>Projects that span multiple categories, from the kernel and userspace
+ to the Ports Collection or external projects.</p>
+ </category>
+
+ <category>
+ <name>kern</name>
+
+ <description>Kernel</description>
+
+ <p>Updates to kernel subsystems/features, driver support,
+ filesystems, and more.</p>
+ </category>
+
+ <category>
+ <name>arch</name>
+
+ <description>Architectures</description>
+
+ <p>Updating platform-specific features and bringing in support
+ for new hardware platforms.</p>.
+ </category>
+
+ <category>
+ <name>bin</name>
+
+ <description>Userland Programs</description>
+
+ <p>Changes affecting the base system and programs in it.</p>
+ </category>
+
+ <category>
+ <name>ports</name>
+
+ <description>Ports</description>
+
+ <p>Changes affecting the Ports Collection, whether sweeping
+ changes that touch most of the tree, or individual ports
+ themselves.</p>
+ </category>
+
+ <category>
+ <name>third</name>
+
+ <description>Third-Party Projects</description>
+
+ <p>Many projects build upon &os; or incorporate components of
+ &os; into their project. As these projects may be of interest
+ to the broader &os; community, we sometimes include brief
+ updates submitted by these projects in our quarterly report.
+ The &os; project makes no representation as to the accuracy or
+ veracity of any claims in these submissions.</p>
+ </category>
+
+ <project cat='team'>
+ <title>FreeBSD Core Team</title>
+
+ <contact>
+ <person>
+ <name>FreeBSD Core Team</name>
+ <email>core@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD Core Team is the governing body of FreeBSD.</p>
+
+ <ul>
+ <li>Core has provisionally accepted the BSD+patent license for
+ use in some cases.
+ The Core Team must approve the import of new BSD+Patent
+ licensed components or
+ the change of license of existing components to the
+ BSD+Patent License.
+ <br/>
+ https://opensource.org/licenses/BSDplusPatent</li>
+
+ <li>Kernel Pseudo Random Number Generator (PRNG)
+ maintainership was updated to
+ reduce the contribution barrier for committers who have
+ demonstrated
+ competence in this part of the tree.</li>
+ <li>Core approved a source commit bit for Paweł Biernacki.
+ Konstantin Belousov
+ &lt;kib@&gt; will mentor Paweł and Mateusz Guzik
+ &lt;mjg@&gt; will be co-mentor.</li>
+ <li>The Core-initiated Git Transition Working Group met over
+ the last quarter,
+ however a report is still forthcoming. Discussions will
+ continue in the
+ fourth quarter of 2019. There are many issues to resolve
+ including how to
+ deal with contrib/, whether to re-generate hashes in the
+ current Git
+ repository, and how to best implement commit testing.</li>
+ </ul>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>FreeBSD Release Engineering Team</title>
+
+ <contact>
+ <person>
+ <name>FreeBSD Release Engineering Team</name>
+ <email>re@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.freebsd.org/releases/11.3R/announce.html">FreeBSD 11.3-RELEASE announcement</url>
+ <url href="https://www.freebsd.org/releases/12.1R/schedule.html">FreeBSD 12.1-RELEASE schedule</url>
+ <url href="https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.1/">FreeBSD 12.1-RELEASE BETA/RC builds</url>
+ <url href="https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/">FreeBSD development snapshots</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD Release Engineering Team is responsible for
+ setting
+ and publishing release schedules for official project
+ releases
+ of FreeBSD, announcing code freezes and maintaining the
+ respective branches, among other things.</p>
+
+ <p>During the third quarter of 2019, the FreeBSD Release
+ Engineering team
+ finished the 11.3-RELEASE cycle, with the final release
+ build started on
+ July 5th and the official announcement sent on July 9th.</p>
+
+ <p>FreeBSD 11.3-RELEASE is the fourth release from the
+ <i>stable/11</i> branch,
+ building on the stability and reliability of 11.2-RELEASE.</p>
+
+ <p>The FreeBSD Release Engineering Team also started work on
+ the upcoming
+ 12.1-RELEASE, which started September 6th. This release
+ cycle is the
+ first "freeze-less" release from the Subversion
+ repository, and the test bed
+ for eliminating the requirement of a hard code freeze on
+ development branches.
+ Commits to the <i>releng/12.1</i> branch still
+ require explicit approval from
+ the Release Engineering Team, however.</p>
+
+ <p>At present, there have been three BETA builds, and so far,
+ two RC builds, with
+ the final 12.1-RELEASE build scheduled for November 4th.</p>
+
+ <p>Additionally throughout the quarter, several development
+ snapshots builds
+ were released for the <i>head</i> and
+ <i>stable/11</i> branches; snapshots for
+ <i>stable/12</i> were released as well although
+ not during the 12.1-RELEASE cycle.</p>
+
+ <p>Much of this work was sponsored by Rubicon Communications,
+ LLC (Netgate)
+ and the FreeBSD Foundation.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>FreeBSD Security Team</title>
+
+ <contact>
+ <person>
+ <name>Security Team</name>
+ <email>secteam@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.freebsd.org/security/">FreeBSD security information</url>
+ </links>
+
+ <body>
+ <p>Several members of the security team met at the Vendor
+ Summit in October to
+ formalize team structure dedicated for architecture and
+ crypto engineering in
+ addition to the existing product security incident
+ response function.</p>
+
+ <p>Since June we have started having fortnightly conference
+ calls to discuss
+ important issues and to collaborate closely on advisories
+ and errata notices in
+ the pipeline.</p>
+
+ <ul>
+ <li>Security advisories sent out in 2019-Q3: 7</li>
+
+ <li>Errata Notices sent out in 2019-Q3: 5</li>
+ </ul>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>Cluster Administration Team</title>
+
+ <contact>
+ <person>
+ <name>Cluster Administration Team</name>
+ <email>clusteradm@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD Cluster Administration Team consists of the
+ people responsible for administering the machines
+ that the Project relies on for its distributed
+ work and communications to be synchronised. In
+ this quarter, the team has worked on the
+ following:</p>
+
+ <ul>
+ <li>Change IPv6 address in TWN site.</li>
+
+ <li>Solved hardware issues in KWC site (with hrs@).</li>
+
+ <li>Moved remaining infrastructure from the YSV (Yahoo!) site
+ to NYI (New York Internet) (peter@).</li>
+
+ <ul><li>YSV hosted most of FreeBSD.org between 2000 and 2019.</li></ul>
+
+ <li>Installed new machines for portmgr@ courtesy of the
+ FreeBSD Foundation.</li>
+
+ <li>Resolved outtages (thanks uqs@) with GitHub exporter,
+ Bugzilla and hg-beta (thanks bapt@).</li>
+
+ <li>PowerPC64 servers are online (power8) building pkgs and
+ reference hosts.</li>
+
+ <li>Ongoing systems administration work:</li>
+
+ <ul><li>Creating accounts for new committers.</li>
+
+ <li>Backups of critical infrastructure.</li>
+
+ <li>Keeping up with security updates in 3rd party software.</li></ul>
+ </ul>
+
+ <p>
+ Work in progress:</p>
+
+ <ul>
+ <li>Review the service jails and service administrators
+ operation.</li>
+
+ <li>South Africa Mirror (JINX) in progress.</li>
+
+ <li>NVME issues on PowerPC64 Power9 blocking dual socket
+ machine from being used as pkg builder.</li>
+
+ <li>Drive upgrade test for pkg builders (SSDs) courtesy of the
+ FreeBSD Foundation.</li>
+
+ <li>Boot issues with Aarch64 reference machines.</li>
+
+ <li>New NYI.net sponsored colocation space in Chicago-land
+ area.</li>
+
+ <li>Setup new host for CI staging environment.</li>
+ </ul>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>Continuous Integration</title>
+
+ <contact>
+ <person>
+ <name>Jenkins Admin</name>
+ <email>jenkins-admin@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Li-Wen Hsu</name>
+ <email>lwhsu@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url>
+ <url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url>
+ <url href="https://wiki.freebsd.org/Jenkins">FreeBSD Jenkins wiki</url>
+ <url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url>
+ <url href="https://github.com/freebsd/freebsd-ci">FreeBSD CI Repository</url>
+ <url href="https://preview.tinyurl.com/y9maauwg">Tickets related to freebsd-testing@</url>
+ <url href="https://wiki.freebsd.org/HostedCI">Hosted CI wiki</url>
+ <url href="https://hackmd.io/@FreeBSD-CI">FreeBSD CI weekly report</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD CI team maintains continuous integration
+ system and related tasks
+ for the FreeBSD project. The CI system regularly checks
+ the committed changes
+ can be successfully built, then performs various tests and
+ analysis of the
+ results. The results from build jobs are archived in an
+ artifact server, for
+ the further testing and debugging needs. The CI team
+ members examine the
+ failing builds and unstable tests, and work with the
+ experts in that area to
+ fix the code or adjust test infrastructure. The details
+ are of these efforts
+ are available in the weekly CI reports.</p>
+
+ <p>We had a testing working group at the <a
+ href="https://wiki.freebsd.org/DevSummit/201909">201909
+ DevSummit</a>
+ lwhsu@ has presented the Testing/CI project status and
+ "how to work with the FreeBSD CI system", slides
+ are available at the DevSummit page.
+ Some contents have been migrated to
+ https://wiki.freebsd.org/Jenkins/Debug , extending
+ is welcomed.</p>
+
+ <p>We continue publishing CI Weekly Report and moved the
+ archive to https://hackmd.io/@FreeBSD-CI</p>
+
+ <p>Work in progress:</p>
+
+ <ul>
+ <li>Collecting and sorting CI tasks and ideas at
+ https://hackmd.io/bWCGgdDFTTK_FG0X7J1Vmg</li>
+
+ <li>Setup the CI stage environment and put the experimental
+ jobs on it</li>
+
+ <li>Extending and publishing the embedded boards testbed</li>
+
+ <li>Implementing automatic tests on bare metal hardware</li>
+
+ <li>Adding drm ports building test against -CURRENT</li>
+
+ <li>Testing and merging pull requests at
+ https://github.com/freebsd/freebsd-ci/pulls</li>
+
+ <li>Planning for running ztest and network stack tests</li>
+
+ <li>Help more 3rd software get CI on FreeBSD through a hosted
+ CI solution</li>
+ </ul>
+
+ <p>
+ Please see freebsd-testing@ related tickets for more WIP
+ information.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='team'>
+ <title>FreeBSD Foundation</title>
+
+ <contact>
+ <person>
+ <name>Deb Goodkin</name>
+ <email>deb@FreeBSDFoundation.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD Foundation is a 501(c)(3) non-profit
+ organization dedicated to
+ supporting and promoting the FreeBSD Project and community
+ worldwide.
+ Funding comes from individual and corporate donations and
+ is used to fund
+ and manage software development projects, conferences and
+ developer summits,
+ and provide travel grants to FreeBSD contributors. The
+ Foundation purchases
+ and supports hardware to improve and maintain FreeBSD
+ infrastructure and
+ provides resources to improve security and quality
+ assurance efforts;
+ publishes marketing material to promote, educate, and
+ advocate for the
+ FreeBSD Project; facilitates collaboration between
+ commercial vendors and
+ FreeBSD developers; and finally, represents the FreeBSD
+ Project in executing
+ contracts, license agreements, and other legal
+ arrangements that require a
+ recognized legal entity.</p>
+
+ <p>Here are some highlights of what we did to help FreeBSD
+ last quarter:</p>
+
+ <p>Partnerships and Commercial User Support
+ We help facilitate collaboration between commercial users
+ and FreeBSD
+ developers. We also meet with companies to discuss their
+ needs and bring
+ that information back to the Project. In Q3, Ed Maste and
+ Deb Goodkin met
+ with a few commercial users in the US. It is not only
+ beneficial for the
+ above, but it also helps us understand some of the
+ applications where
+ FreeBSD is used. We were also able to meet with a good
+ number of commercial
+ users at vBSDCon and EuroBSDCon. These venues provide an
+ excellent
+ opportunity to meet with commercial and individual users
+ and contributors
+ to FreeBSD.</p>
+
+ <p>Fundraising Efforts
+ Our work is 100% funded by your donations. We are
+ continuing to work hard
+ to get more commercial users to give back to help us
+ continue our work
+ supporting FreeBSD. More importantly, we'd like to thank
+ our individual
+ donors for making $10-$1,000 donations last quarter, for
+ more than $16,000!</p>
+
+ <p>Please consider
+ <a href="https://www.FreeBSDfoundation.org/donate/">making
+ a donation</a> to help us
+ continue and increase our support for FreeBSD!</p>
+
+ <p>We also have the Partnership Program, to provide more
+ benefits for our
+ larger commercial donors. Find out more information at
+ <a
+ href="https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/">www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/</a>
+ and share with your companies.</p>
+
+ <p>OS Improvements
+ The Foundation supports software development projects to
+ improve the FreeBSD
+ operating system through our full time technical staff,
+ contractors, and
+ project grant recipients. They maintain and improve
+ critical kernel
+ subsystems, add new features and functionality, and fix
+ problems.</p>
+
+ <p>Over the last quarter there were 345 commits to the
+ FreeBSD base system
+ repository sponsored by the FreeBSD Foundation - this
+ represents about
+ one fifth of all commits during this period. Many of these
+ projects have
+ their own entries in this quarterly report (and are not
+ repeated here).</p>
+
+ <p>Foundation staff member Konstantin Belousov committed many
+ improvements to
+ multiple kernel subsystems, as well as low-level 32-bit
+ and 64-bit x86
+ infrastructure. These included fixes for robust mutexes,
+ unionfs, the
+ out of memory (OOM) handler, and per-cpu allocators.</p>
+
+ <p>Additional work included fixes for security issues and
+ introduction and
+ maintenance of vulnerability mitigations, and improving
+ POSIX conformance.</p>
+
+ <p>Ed Maste committed a number of minor security bug fixes
+ and improvements,
+ as well as the first iteration of a tool for editing the
+ mitigation control
+ ELF note. Additional work included effort on build
+ infrastructure and the
+ tool chain.</p>
+
+ <p>Clang's integrated assembler (IAS) is now used more
+ widely, as part of the
+ path to retiring the assembler from GNU binutils 2.17.50.
+ The readelf tool
+ now decodes some additional ELF note information.</p>
+
+ <p>Ed also enabled the Linuxulator (Linux binary support
+ layer) on arm64, and
+ added a trivial implementation of the renameat2 system
+ call (handling common
+ options).</p>
+
+ <p>Mark Johnston added Capsicum support to a number of ELF
+ Tool Chain utilities,
+ and committed a number of other Capsicum kernel and
+ userland fixes.</p>
+
+ <p>Mark worked on a number of changes related to security
+ improvements, including
+ integration and support of the Syzkaller automated system
+ call fuzzer, and
+ fixing issues identified by Syzkaller. Other changes
+ included addressing
+ failures caused by refcount wraparound, improvements to
+ the <tt>prot_max</tt> memory
+ protection. Other work included NUMA, locking, kernel
+ debugging, RISC-V and
+ arm64 kernel improvements.</p>
+
+ <p>Edward Napierala continued working on Linuxulator
+ improvements over the
+ quarter. The primary focus continued to be tool
+ improvements - strace is now
+ more usable for diagnosing issues with Linux binaries
+ running under the
+ Linuxulator. That said, as with previous work a number of
+ issues have been
+ fixed along the way. These are generally minor issues with
+ a large impact -
+ for example, every binary linked against up-to-date glibc
+ previously
+ segfaulted on startup. This is now fixed.</p>
+
+ <p>Continuous Integration and Quality Assurance
+ The Foundation provides a full-time staff member who is
+ working on improving
+ our automated testing, continuous integration, and overall
+ quality assurance
+ efforts.</p>
+
+ <p>During the third quarter of 2019, Foundation staff
+ continued to improve the
+ project's CI infrastructure, worked with contributors to
+ fix the failing build
+ and test cases, and worked with other teams in the Project
+ for their testing
+ needs. We added several new CI jobs and worked on getting
+ the hardware
+ regression testing lab ready.</p>
+
+ <p>Li-Wen Hsu gave presentations "Testing/CI status update"
+ and "How to work with
+ the FreeBSD CI system" at the
+ <a href="https://wiki.freebsd.org/DevSummit/201909">201909
+ DevSummit</a>.
+ Slides are available at the DevSummit page.</p>
+
+ <p>We continue publishing the CI weekly report on the
+ <a
+ href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">freebsd-testing@</a>.
+ mailing list, and an <a
+ href="https://hackmd.io/@freebsd-ci">archive</a>
+ is available.</p>
+
+ <p>See the FreeBSD CI section of this report for completed
+ work items and
+ detailed information.</p>
+
+ <p>Supporting FreeBSD Infrastructure
+ The Foundation provides hardware and support to improve
+ the FreeBSD
+ infrastructure. Last quarter, we continued supporting
+ FreeBSD hardware
+ located around the world.</p>
+
+ <p>FreeBSD Advocacy and Education
+ A large part of our efforts are dedicated to advocating
+ for the Project.
+ This includes promoting work being done by others with
+ FreeBSD; producing
+ advocacy literature to teach people about FreeBSD and help
+ make the path to
+ starting using FreeBSD or contributing to the Project
+ easier; and attending
+ and getting other FreeBSD contributors to volunteer to run
+ FreeBSD events,
+ staff FreeBSD tables, and give FreeBSD presentations.</p>
+
+ <p>The FreeBSD Foundation sponsors many conferences, events,
+ and summits around
+ the globe. These events can be BSD-related, open source,
+ or technology events
+ geared towards underrepresented groups. We support the
+ FreeBSD-focused events
+ to help provide a venue for sharing knowledge, to work
+ together on projects,
+ and to facilitate collaboration between developers and
+ commercial users.
+ This all helps provide a healthy ecosystem. We support the
+ non-FreeBSD events
+ to promote and raise awareness of FreeBSD, to increase the
+ use of FreeBSD in
+ different applications, and to recruit more contributors
+ to the Project.</p>
+
+ <p>Check out some of the advocacy and education work we did
+ last quarter:</p>
+
+ <ul>
+ <li>Sponsored USENIX 2019 Annual Technical Conference as an
+ Industry Partner</li>
+
+ <li>Represented FreeBSD at OSCON 2019 in Portland, OR</li>
+
+ <li>Represented FreeBSD at COSCUP 2019 in Taiwan</li>
+
+ <li>Presented at the Open Source Summit, North American in San
+ Diego, CA</li>
+
+ <li>Executive Director Deb Goodkin was interviewed by TFiR
+ https://www.freebsdfoundation.org/news-and-events/latest-news/tfir-interview-freebsd-meets-linux-at-the-open-source-summit/</li>
+
+ <li>Sponsored FreeBSD Hackathon at vBSDcon 2019 in Reston, VA</li>
+
+ <li>Sponsored the attendee bags and attended vBSDcon 2019 in
+ Reston VA</li>
+
+ <li>Represented FreeBSD at APNIC-48 in Chiang Mai, Thailand</li>
+
+ <li>Represented FreeBSD at MNNOG-1 in Ulaanbaatar, Mongolia</li>
+
+ <li>Served as an administrator for the Project’s Google Summer
+ of Code Session. See the Google Summer of Code
+ section of this report for more information.</li>
+
+ <li>Sponsored FreeBSD Developers Summit at EuroBSDCon in
+ Lillehammer, Norway</li>
+
+ <li>Sponsored and attended EuroBSDcon 2019 in Lillehammer,
+ Norway</li>
+
+ <li>Applied and was accepted for a FreeBSD Miniconf at
+ linux.conf.au, in Gold Coast, Australia, Jan 14,
+ 2020</li>
+
+ <li>Our FreeBSD talk was accepted at seaGL, Seattle, WA,
+ November 15 and 16.</li>
+ </ul>
+
+ <p>
+ We continued producing FreeBSD advocacy material to help
+ people promote
+ FreeBSD. Learn more about our recent efforts to advocate
+ for FreeBSD
+ around the world:
+ https://www.freebsdfoundation.org/blog/freebsd-around-the-world/</p>
+
+ <p>Our Faces of FreeBSD series is back. Check out the latest
+ post:
+ <a
+ href="https://www.freebsdfoundation.org/blog/faces-of-freebsd-2019-roller-angel/">Roller
+ Angel</a>.</p>
+
+ <p>Read more about our conference adventures in the
+ conference recaps and trip
+ reports in our monthly newsletters:
+
+ https://www.freebsdfoundation.org/news-and-events/newsletter/</p>
+
+ <p>We help educate the world about FreeBSD by publishing the
+ professionally
+ produced FreeBSD Journal. As we mentioned previously, the
+ FreeBSD Journal
+ is now a free publication. Find out more and access the
+ latest issues at
+ https://www.FreeBSDfoundation.org/journal/.</p>
+
+ <p>You can find out more about
+ <a
+ href="https://www.FreeBSDfoundation.org/news-and-events/">events
+ we attended and upcoming events</a>.</p>
+
+ <p>We opened our official FreeBSD Swag Store. Get stickers,
+ shirts, mugs and
+ more at <a
+ href="https://www.zazzle.com/store/shopfreebsd">ShopFreeBSD</a>.</p>
+
+ <p>We have continued our work with a new website developer to
+ help us improve
+ our website. Work has begun to make it easier for
+ community members to find
+ information and to make the site more efficient.</p>
+
+ <p>Legal/FreeBSD IP
+ The Foundation owns the FreeBSD trademarks, and it is our
+ responsibility to
+ protect them. We also provide legal support for the core
+ team to investigate
+ questions that arise.</p>
+
+ <p>Go to http://www.FreeBSDfoundation.org to find out how we
+ support FreeBSD and
+ how we can help you!</p>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>FreeBSD Graphics Team status report</title>
+
+ <contact>
+ <person>
+ <name>FreeBSD Graphics Team</name>
+ <email>x11@freebsd.org</email>
+ </person>
+ <person>
+ <name>Niclas Zeising</name>
+ <email>zeising@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/FreeBSDDesktop">Project GitHub page</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD X11/Graphics team maintains the lower levels
+ of the FreeBSD graphics
+ stack.
+ This includes graphics drivers, graphics libraries such as
+ the
+ MESA OpenGL implementation, the X.org xserver with related
+ libraries and
+ applications, and Wayland with related libraries and
+ applications.</p>
+
+ <p>During the last period, several changes have been made,
+ but most of them has
+ been behind the scene.
+ We have also worked on general clean up of old xorg ports
+ that have been
+ deprecated upstream.</p>
+
+ <p>The ports infrastructure for xorg ports and ports that
+ depend on xorg ports have
+ been updated.
+ We have switched <tt>USE_XORG</tt> and <tt>XORG_CAT</tt>
+ to use the <tt>USES</tt> framework, instead
+ of the old way of including <tt>bsd.xorg.mk</tt> from
+ <tt>bsd.port.mk</tt>.
+ This infrastructure work has been fairly substantial, and
+ new ports depending on
+ xorg ports should add <tt>USES=xorg</tt> to their
+ makefiles.
+ As part of this <tt>bsd.xorg.mk</tt> was split up, and the
+ <tt>XORG_CAT</tt> part was split
+ out to <tt>USES=xorg-cat</tt>.
+ This is used for the xorg ports themselves, and sets up a
+ common environment for
+ building all xorg ports.
+ In addition, framework for pulling xorg ports directly
+ from freedesktop.org
+ gitlab was added, which will make improve development and
+ testing, since it
+ makes it possible to create ports of unreleased versions.
+ Further improvements in this area includes framework for
+ using meson instead of
+ autotools for building xorg ports.
+ This is still a work in progress.</p>
+
+ <p>We have also worked to clean up and deprecate several old
+ xorg ports and
+ libraries.
+ Some of these ports have already been removed, and some
+ are still waiting on
+ removal after a sufficient deprecation period.
+ Most notably amongst the deprecations are
+ <tt>x11/libXp</tt>, which required to fix
+ several dependencies.
+ Several other old libraries have also been deprecated,
+ such as <tt>x11/Xxf86misc</tt>,
+ <tt>x11-fonts/libXfontcache</tt> and
+ <tt>graphics/libGLw</tt>.
+ Some applications and drivers have also been deprecated
+ during the period.
+ With the remaining removals in this area, we should be up
+ to speed with
+ deprecations upstream.
+ We are currently investigating if there are new software
+ added upstream that we
+ need to port to FreeBSD.</p>
+
+ <p>We have also continued our regularly scheduled bi-weekly
+ meetings.</p>
+
+ <p>People who are interested in helping out can find us on
+ the x11@FreeBSD.org
+ mailing list, or on our gitter chat: <a
+ href="https://gitter.im/FreeBSDDesktop/Lobby">https://gitter.im/FreeBSDDesktop/Lobby</a>.
+ We are also available in #freebsd-xorg on EFNet.</p>
+
+ <p>We also have a team area on GitHub where our work
+ repositories can be found:
+ <a
+ href="https://github.com/FreeBSDDesktop">https://github.com/FreeBSDDesktop</a></p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Google Summer of Code 2019</title>
+
+ <contact>
+ <person>
+ <name>Summer of Code Admins</name>
+ <email>soc-admins@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/SummerOfCode2019Projects">2019 Summer of Code Project Wikis</url>
+ <url href="https://summerofcode.withgoogle.com/archive/2019/organizations/6504969929228288/">2019 Summer of Code Projects</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD Project is pleased to have participated in
+ Google Summer of Code 2019 marking our 14th year of
+ participation.
+ This year we had six successful projects:</p>
+
+ <ul>
+ <li><i>Dual-stack ping command</i> by Ján Sučan</li>
+
+ <li><i>Firewall test suite</i> by Ahsan Barkati</li>
+
+ <li><i>Kernel sanitizers</i> by Costin Carabaș</li>
+
+ <li><i>MAC policy on IP addresses for FreeBSD
+ Jail</i> by Shivank Garg</li>
+
+ <li><i>Separation of ports build process from local
+ installation</i> by Theron Tarigo</li>
+
+ <li><i>Virtual memory compression</i> by
+ Paavo-Einari Kaipila</li>
+ </ul>
+
+ <p>
+ We thank Google for the opportunity to work with these
+ students and hope
+ they continue to work with FreeBSD in the future.</p>
+
+ </body>
+
+ <sponsor>
+ Google Summer of Code
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>GSoC'19 Project - MAC policy on IP addresses in Jail: mac_ipacl</title>
+
+ <contact>
+ <person>
+ <name>Shivank Garg</name>
+ <email>shivank@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://reviews.freebsd.org/D20967">FreeBSD's Phabricator Differential Link</url>
+ <url href="https://github.com/freebsd/freebsd/compare/master...shivankgarg98:shivank_MACPolicyIPAddressJail">Github Diff Link</url>
+ <url href="https://wiki.freebsd.org/SummerOfCode2019Projects/MACPolicyIPAddressJail">Project Wiki Page</url>
+ </links>
+
+ <body>
+ <p><b>About -</b> With the introduction of VNET(9)
+ in FreeBSD, Jails are free to
+ set their IP addresses. However, this privilege may need
+ to be limited by
+ the host as per its need for multiple security reasons.
+ This project uses mac(9) for an access control framework
+ to impose
+ restrictions on FreeBSD jails according to rules defined
+ by the root of the
+ host using sysctl(8). It involves the development of a
+ dynamically loadable
+ kernel module (mac_ipacl) based on The TrustedBSD MAC
+ Framework to
+ implement a security policy for configuring the network
+ stack.
+ This project allows the root of the host to define the
+ policy rules to
+ limit the root of a jail to a set of IP (v4 or v6)
+ addresses and/or subnets
+ for a set of interfaces.</p>
+
+ <p>Features this new MAC policy module are:</p>
+
+ <ul>
+ <li>The host can define one or more lists of IP
+ addresses/subnets
+ for the jail to choose from.</li>
+
+ <li>The host can restrict the jail from setting certain IP
+ addresses or
+ prefixes (subnets).</li>
+
+ <li>The host can restrict this privilege to a few network
+ interfaces.</li>
+ </ul>
+
+ <p>
+ <b>Implementation -</b> The mac_ipacl module is
+ a loadable kernel module. It
+ implements mac checks in netinet/in.c and netinet6/in6.c
+ to check the IP
+ addresses requested by jail. The idea to implement these
+ checks at these
+ places comes from the fact that SIOCAIFADDR (for IPv4) and
+ SIOCAIFADDR_IN6 (for IPv6) ioctl handlers are defined for
+ adding the IP
+ addresses to an interface. This is used by ifconfig (in
+ userspace) for
+ setting the IP address. The MAC Framework acts as
+ multiplexer between the
+ netinet and the module. The requested IP and the
+ credentials are checked
+ with the rules in mac_ipacl and output is returned
+ accordingly to netinet.
+ The module can be tuned with various sysctl and similarly,
+ policy rules are
+ also be defined with sysctl.</p>
+
+ <p><b>TestSuite -</b> Test scripts integrated with
+ kyua and ATF are included with
+ the module.</p>
+
+ <p><b>Using the module -</b> I have written a man
+ page for the module. Please
+ refer to the mac_ipacl(4) for using the new MAC module and
+ various examples.</p>
+
+ <p><b>Final Deliverables -</b></p>
+
+ <ul>
+ <li>A loadable kernel module - <a
+ href="https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/sys/security/mac_ipacl">mac_ipacl
+ in sys/security/mac_ipacl</a></li>
+ <li>ATF tests for the module in <a
+ href="https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/tests/sys/mac/ipacl">tests/sys/mac/ipacl</a></li>
+ <li>A man page for this new mac module - mac_ipacl.4 in
+ <a
+ href="https://github.com/shivankgarg98/freebsd/blob/shivank_MACPolicyIPAddressJail/share/man/man4/mac_ipacl.4">share/man/man4/mac_ipacl.4</a></li>
+ </ul>
+
+ <p>This is a new project, developed as part of <b>Google
+ Summer of Code'19</b>
+ under the guidance of <b>Bjoern A. Zeeb</b>
+ &lt;<a href="mailto:bz@FreeBSD.org">bz@FreeBSD.org</a>&gt;. The module is
+ <b>reviewed</b> and <b>Revision for this project
+ is accepted and ready to
+ land</b>. It is yet to be merged with FreeBSD HEAD, and
+ waiting to be tested
+ by few more hands in the industry.</p>
+
+ <p>I'll be very thankful if you can give this module a try
+ and share your
+ valuable experience about it. Please be free to share your
+ ideas and
+ feedback on this module and please do not hesitate to send
+ me an email.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>FUSE</title>
+
+ <contact>
+ <person>
+ <name>Alan Somers</name>
+ <email>asomers@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>FUSE (File system in USErspace) allows a userspace program
+ to
+ implement a file system. It is widely used to support
+ out-of-tree file
+ systems like NTFS, as well as for exotic pseudo file
+ systems like
+ sshfs. FreeBSD's fuse driver was added as a GSoC project
+ in 2012.
+ Since that time, it has been largely neglected. The FUSE
+ software is
+ <a
+ href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&amp;known_name=fusefs&amp;list_id=289348&amp;query_based_on=fusefs&amp;query_format=advanced&amp;short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&amp;short_desc_type=anywordssubstr">buggy</a>
+ and out-of-date. Our implementation is about 11 years
+ behind.</p>
+
+ <p>I completed this work during Q3. I fixed a few
+ newly-introduced bugs, fixed a
+ long-standing sendfile bug that affects FUSE
+
+ ([236466](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236466))
+ and merged
+ everything to head and stable/12. Then I fixed the
+ resulting Coverity CIDs.
+ There have been no new FUSE-related bug reports, so I can
+ only assume that
+ everything is working great. Report any problems to
+ asomers@FreeBSD.org.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>NFS Version 4.2 implementation</title>
+
+ <contact>
+ <person>
+ <name>Rick Macklem</name>
+ <email>rmacklem@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>RFC-7862 describes a new minor revision to the NFS Version
+ 4 protocol.
+ This project implements this new minor revision.</p>
+
+ <p>The NFS Version 4 Minor Version 2 protocol adds several
+ optional
+ features to NFS, such as support for SEEK_DATA/SEEK_HOLE,
+ file
+ copying done on the server that avoids data transfer over
+ the wire
+ and support for posix_fallocate(), posix_fadvise().
+ Hopefully these features can improve performance for
+ certain applications.</p>
+
+ <p>The implementation is now nearing completion and recent
+ work has been
+ mostly testing. A cycle of interoperability testing with
+ Linux has
+ just been completed. The main area that still needs
+ testing is use
+ of the pNFS server with NFSv4.2 and that should start
+ soon.
+ Once testing of pNFS is completed, I believe the code is
+ ready to
+ be incorporated into FreeBSD head/current.</p>
+
+ <p>Testing by others would be appreciated. The modified
+ kernel can be
+ found at https://svn.freebsd.org/base/projects/nfsv42/sys
+ and should
+ run with a recent FreeBSD head/current system. Client
+ mounts need the
+ "minorversion=2" mount option to enable this protocol.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>FAT / msdosfs support for makefs(8)</title>
+
+ <contact>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>In order to streamline the process of creating install or
+ virtual
+ machine system images we needed FAT filesystem support in
+ makefs(8).
+ Makefs was originally developed in NetBSD, and FAT support
+ was added
+ there not much later, but after the tool was ported to
+ FreeBSD.</p>
+
+ <p>Siva Mahadevan, one of the FreeBSD Foundation's interns
+ from the
+ University of Waterloo, worked on porting FAT support from
+ NetBSD.
+ I <a href="https://reviews.freebsd.org/D16438">rebased and
+ updated</a> Siva's
+ work, and <a
+ href="https://reviews.freebsd.org/rS351273">committed</a>
+ it during
+ this quarter. After a few follow-up fixes we are able to
+ build FAT
+ filesystem images without using md(4) and without
+ requiring root.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>syzkaller on FreeBSD</title>
+
+ <contact>
+ <person>
+ <name>Andrew Turner</name>
+ <email>andrew@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Michael Tuexen</name>
+ <email>tuexen@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Samy Al Bahra</name>
+ <email>sbahra@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>See the syzkaller entry in the 2019q1 quarterly report for
+ an
+ introduction to syzkaller.</p>
+
+ <p>Work has continued on fixing bugs uncovered by syzkaller.
+ Over a dozen
+ kernel bugs fixed in the past three months have been
+ directly attributed
+ to syzkaller, and a number of syzkaller reproducers have
+ been
+ incorporated into our test suite.</p>
+
+ <p>backtrace.io, via Samy, has graciously provided a large
+ server for
+ running a dedicated syzkaller instance to fuzz FreeBSD
+ under bhyve.
+ Though syzbot, the public syzkaller instance run by
+ Google, already
+ fuzzes FreeBSD, it has proven fruitful to run multiple
+ syzkaller
+ instances: different instances find different bugs, and
+ syzkaller.backtrace.io allows us to experiment with
+ FreeBSD-specific
+ extensions. In particular, this instance currently uploads
+ data about
+ each crash to backtrace.io, making it much easier to
+ triage and analyze
+ crashes. We plan to make this service generally available
+ to FreeBSD
+ developers in the near future.</p>
+
+ <p>Going forward we will continue to extend syzkaller
+ coverage and make it
+ simpler for users and developers to run private instances,
+ and
+ optionally collect kernel crash information for debugging
+ or for
+ submission.</p>
+
+ </body>
+
+ <sponsor>
+ backtrace.io
+ </sponsor>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Rockchip RK3399 SoC's eMMC support</title>
+
+ <contact>
+ <person>
+ <name>Ganbold Tsagaankhuu</name>
+ <email>ganbold@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The followings features have been added to support RK3399
+ SoC eMMC on FreeBSD:</p>
+
+ <ul>
+ <li>Extended simple_mfd driver to expose a syscon interface if
+ that node is also compatible with syscon. For instance,
+ Rockchip RK3399's GRF (General Register Files) is
+ compatible
+ with simple-mfd as well as syscon and has devices like
+ usb2-phy, emmc-phy and pcie-phy etc. under it.</li>
+
+ <li>Made Rockchip's General Register Files driver the subclass
+ of Simple MFD driver</li>
+
+ <li>Added driver for Rockchip RK3399 eMMC PHY.</li>
+
+ <li>Added eMMC support codes for Rockchip RK3399 SoC.</li>
+
+ <li>All above was tested on NanoPC-T4 board.</li>
+ </ul>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>TPM2 Software Stack (TSS2)</title>
+
+ <contact>
+ <person>
+ <name>D Scott Phillips</name>
+ <email>scottph@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://tpm2-tss.readthedocs.io/en/latest/index.html">tpm2-tss Documentation</url>
+ <url href="https://github.com/tpm2-software/">tpm2 Source Repository</url>
+ <url href="https://lists.01.org/postorius/lists/tpm2.lists.01.org/">tpm2 mailing list</url>
+ <url href="ircs://chat.freenode.net:6697/tpm2.0-tss">tpm2 irc channel</url>
+ </links>
+
+ <body>
+ <p>Intel has contributed ports of the TPM2 Software Stack to
+ the ports tree, with
+ the new ports securtity/tpm2-tss, security/tpm2-tools,
+ security/tpm2-abrmd.
+ <tt>tpm2-tss</tt> contains a set of libraries which expose
+ various TPM2 APIs for using
+ a TPM conforming to the TCG TPM 2.0 specification.
+ <tt>tpm2-tools</tt> provides a set
+ of command line tools which use the <tt>tpm2-tss</tt>
+ libraries to perform tpm
+ operations. Finally, <tt>tpm2-abrmd</tt> is a userspace
+ daemon which acts as a TPM
+ Access Broker and Resource Manager, multiplexing many TPM
+ users onto a single
+ TPM device.</p>
+
+ <p>Sponsored by: Intel Corporation</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Improving laptop support</title>
+
+ <contact>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD Foundation would like to ensure that running
+ FreeBSD on
+ contemporary hardware, including laptops, remains viable.
+ To that end
+ we plan to purchase the latest generation of one or more
+ of a family
+ of laptops preferred by members of the FreeBSD community,
+ evaluate the
+ existing state of hardware support, and implement missing
+ hardware
+ support where possible.</p>
+
+ <p>As the first laptop for this project we have selected a
+ 7th Generation
+ Lenovo X1 Carbon.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='bin'>
+ <title>gets(3) retirement</title>
+
+ <contact>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>gets is an obsolete C library routine for reading a string
+ from standard
+ input. It was removed from the C standard as of C11
+ because there was no
+ way to use it safely. Prompted by a comment during Paul
+ Vixie's talk at
+ vBSDCon 2017 I started investigating what it would take to
+ remove gets
+ from libc.</p>
+
+ <p><a href="https://reviews.freebsd.org/D12298">The patch</a>
+ was posted to Phabricator
+ and refined several times, and the portmgr team performed
+ several
+ <a href="https://bugs.freebsd.org/222796">exp-runs</a> to
+ identify ports broken by
+ the removal. Symbol versioning is used to preserve binary
+ compatibility
+ for existing software that uses gets.</p>
+
+ <p>The change was <a
+ href="https://reviews.freebsd.org/rS351659">committed</a>
+ in
+ September, and will be in FreeBSD 13.0.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='kern'>
+ <title>Kernel Mapping Protections</title>
+
+ <contact>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>Modern CPU architectures have the ability to flag memory
+ mappings as
+ "no-execute" (NX), which prevents that memory from being
+ executed by a
+ processor. NX mappings are an important security
+ mitigation since they help
+ segregate code and data, blocking unintentional execution
+ of memory whose
+ contents is controlled by an attacker. W^X (write XOR
+ execute) is a security
+ policy which disallows the creation of mappings that are
+ simultaneously
+ writeable and executable. Under this policy, memory whose
+ contents can be
+ modified must be mapped with the NX flag. This policy
+ makes it harder to exploit
+ bugs that permit an attacker to arbitrarily overwrite
+ data.</p>
+
+ <p>FreeBSD has long made use of the NX flag for userspace
+ mappings whenever
+ possible, but only in the past several years has it been
+ applied to kernel
+ mappings. A recent project has sought to implement a
+ W^X-by-default policy for
+ the amd64 kernel by completing an audit of the remaining
+ executable mappings in
+ the kernel, and making modifications to either apply the
+ NX bit to those
+ mappings or to make them read-only. This work has landed
+ in HEAD and will be
+ available in FreeBSD 13.0 and 12.2. Similar work for other
+ CPU architectures is
+ also planned.</p>
+
+ <p>To help audit kernel mapping protections, the
+ vm.pmap.kernel_maps sysctl was
+ added; it dumps a snapshot of the kernel's page table
+ entries and their
+ attributes. This way, mappings violating the W^X policy
+ can easily be
+ discovered and investigated, and the sysctl provides
+ information useful to
+ anyone interested in kernel memory layout.</p>
+
+ <p>With a few rare exceptions, the only kernel mappings which
+ require execute
+ permission are those of the kernel executable itself, and
+ loadable kernel
+ modules. A number of other regions of memory were
+ unnecessarily being mapped
+ without NX, and these were identified and corrected first.
+ To address the
+ kernel code mappings, the amd64 kernel linker script was
+ modified to pad the
+ .text segment to a 2MB boundary. To improve performance,
+ the kernel creates
+ superpage mappings of its .text segment, but this means
+ that any data cohabiting
+ the final 2MB .text mapping is mapped with execute
+ permissions. The padding
+ allows executable code to be segregated from data which
+ follows in the kernel
+ image, avoiding this problem and maintaining the superpage
+ optimization at the
+ expense of some wasted RAM.</p>
+
+ <p>Enforcing W^X turned out to be somewhat trickier. Unlike
+ other CPU
+ architectures supported by FreeBSD, amd64 kernel modules
+ are linked as
+ relocatable object files, i.e., .o files. (On other
+ architectures, they are
+ dynamically shared objects (DSOs, or .so files), as one
+ might naively expect.)
+ The use of .o files means that amd64 kernel modules
+ contain more efficient code
+ than they would if linked as DSOs, since DSOs inherently
+ make use of certain
+ types of indirection which allow shared libraries to be
+ loaded at arbitrary
+ addresses, and this indirection is useless in the kernel.
+ As part of this
+ project an attempt was made to switch amd64 to using DSOs
+ as well, since the
+ cost of this indirection can largely be mitigated with
+ modern toolchains, but it
+ was found that the use of DSOs would also force a change
+ to the code model used
+ when compiling amd64 kernel code, resulting in a further
+ performance penalty.</p>
+
+ <p>The main obstacle with the use of .o files is that
+ sections are not page-aligned
+ by default; the segregation of sections with differing
+ mapping protection
+ requirements is done by the static linker when linking a
+ DSO or executable file.
+ Since mapping protections are applied at the granularity
+ of the page size (4KB
+ on amd64), the overlap of sections within a page causes
+ problems since, for
+ example, the end of the read-only .text section may
+ overlap with the beginning
+ of the read-write .data section. One possible solution is
+ to perform any
+ required section reordering and padding at kernel module
+ load time, but this
+ approach breaks debugging tools such as dtrace(1) and kgdb
+ which assume that the
+ kernel linker does not modify the layout of loadable
+ modules. As a result, an
+ amd64 kernel module linker script is now used to insert
+ padding for specific
+ sections. Finally, the kernel linker was modified to
+ restrict mapping
+ protections based on section flags.</p>
+
+ <p>As a result of all of this, amd64 kernels now boot without
+ any writeable,
+ executable mappings. Though some of the work was
+ architecture-specific, much of
+ it can and will be leveraged to provide the same policy
+ for our other supported
+ architectures.</p>
+
+ </body>
+
+ <sponsor>
+ Netflix
+ </sponsor>
+
+ </project>
+
+ <project cat='kern'>
+ <title>PROT_MAX mmap/mprotect maximum protections API</title>
+
+ <contact>
+ <person>
+ <name>Brooks Davis</name>
+ <email>brooks@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://reviews.freebsd.org/rS349240">PROT_MAX commit</url>
+ </links>
+
+ <body>
+ <p>Unix-like systems provide the <tt>mmap(2)</tt> system call
+ to allocate memory or
+ map files or devices into memory with specified access
+ protection, and the
+ <tt>mprotect(2)</tt> system call to change protections on
+ mapped memory. Protection
+ flags specify whether the memory may be read, written,
+ and/or executed
+ (<tt>PROT_READ</tt>, <tt>PROT_WRITE</tt>, <tt>PROT_EXEC</tt>
+ respectively). Traditionally,
+ <tt>mprotect(2)</tt> can be used to set any desired
+ protections (except that a
+ shared mapping of a file opened read-only cannot have
+ <tt>PROT_WRITE</tt> set).</p>
+
+ <p>A new macro <tt>PROT_MAX()</tt> adds a facility for
+ specifying the maximum possible
+ protection flags for <tt>mmap(2)</tt> and
+ <tt>mprotect(2)</tt> calls. The program can then
+ specify whether a mapping may be changed in the future to
+ allow a given access
+ protection. For example, a memory mapping can be set such
+ that it can have
+ read and write protections set, but may never be made
+ executable.</p>
+
+ <p>Maximum protection values are provided to the
+ <tt>PROT_MAX()</tt> macro, and are
+ OR'd with regular protection values.</p>
+
+ <p>This change allows (e.g.) a region that must be writable
+ during run-time
+ linking or JIT code generation to be made permanently
+ read+execute after
+ writes are complete. This complements Write-XOR-Execute
+ (W^X) protections
+ available on other operating systems, allowing more
+ precise control by the
+ programmer.</p>
+
+ <p>For example, to request memory that cannot be made
+ executable:
+ <ttt>
+ mmap(NULL, size, PROT_READ | PROT_WRITE |
+ PROT_MAX(PROT_READ | PROT_WRITE),
+ MAP_ANON, -1, 0);
+ </ttt></p>
+
+ <p>and to request memory that may have execute permission
+ enabled later on, but
+ is not currently executable:</p>
+
+ <p><ttt>
+ mmap(NULL, size,
+ PROT_READ | PROT_WRITE | PROT_MAX(PROT_READ | PROT_WRITE |
+ PROT_EXECUTE),
+ MAP_ANON, -1, 0);
+ </ttt></p>
+
+ <p>This change alters mprotect argument checking and returns
+ an error when
+ unhandled protection flags are set. This differs from
+ POSIX (in that POSIX
+ only specifies an error if a valid permission can not be
+ set), but is the
+ documented behavior on Linux and more closely matches
+ historical mmap behavior.</p>
+
+ <p>In addition to explicit setting of the maximum
+ permissions, an experimental
+ sysctl <tt>vm.imply_prot_max</tt> causes mmap to assume
+ that the initial permissions
+ requested should be the maximum when the sysctl is set to
+ 1. This behavior is
+ known to break code that uses <tt>PROT_NONE</tt>
+ reservations before mapping contents
+ into part of the reservation. A later version of this work
+ is expected to
+ provide per-binary and per-process opt-in/out options and
+ this sysctl may be
+ removed in its current form. As such it is undocumented.</p>
+
+ <p>While these flags are non-portable, they can be used in
+ portable code with
+ simple ifdefs to expand <tt>PROT_MAX()</tt> to 0.</p>
+
+ <p>Sponsors: DARPA, AFRL</p>
+
+ </body>
+
+ </project>
+
+ <project cat='kern'>
+ <title>Kernel ZLIB Update</title>
+
+ <contact>
+ <person>
+ <name>Xin Li</name>
+ <email>delphij@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Yoshihiro Ota</name>
+ <email>ota@j.email.ne.jp</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The ZLIB is a compression library is widely used in
+ various software.
+ The FreeBSD system had used an ancient (over 20 year-old)
+ version
+ of zlib (version 1.0.4) and total of 3 versions, one in
+ user-land,
+ one in ZFS, and one in kernel.
+ Xin and Yoshihiro upgraded zlib to the latest and
+ eliminated 2 extra copies.
+ Along the efforts, zlib version was upgraded to 1.2.11,
+ netgraph's ppp is
+ re-implemented to use the standard zlib, and removed
+ unmaintained code.
+ We now only have one and the latest version of zlib in
+ FreeBSD code base,
+ new compress, compress2, and uncompress APIs exposed in
+ the kernel,
+ and importing changes from zlib will be simple.</p>
+
+ <p>Kernel zlib changes</p>
+
+ <ul>
+ <li><a href="https://reviews.freebsd.org/D20193">sys/crc32.h
+ is split to avoid object file name conflict with
+ ZLIB's</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D20191">contrib/zlib
+ is moved to sys/contrib/zlib</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D19706">Kernel
+ started switching to sys/contrib/zlib and ZFS copy
+ dropped</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D21156">Kernel
+ zcalloc is introduced and compress, compress2, and
+ uncompress APIs are exposed to kernel</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D21375">Removed zlib
+ 1.0.4 from kernel</a></li>
+ </ul>
+
+ <p>
+ Kernel zlib user updates</p>
+
+ <ul>
+ <li><a href="https://reviews.freebsd.org/D21176">kern_ctf.c
+ updated</a></li>
+
+ <li><a
+ href="https://reviews.freebsd.org/D20222">opencryptodeflate
+ updated</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D20271">geom_uzip
+ updated</a></li>
+
+ <li><a
+ href="https://reviews.freebsd.org/D21408">subr_compressor
+ updated</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D20272">if_mxge
+ updated</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D21175">bxe
+ updated</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D21186">ng_deflate
+ updated</a></li>
+ </ul>
+
+ <p>
+ Legacy code removals</p>
+
+ <ul>
+ <li><a href="https://reviews.freebsd.org/D20190">Removed MIPS
+ zlib elf trampoline</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D20248">Removed kgzip
+ and kgzldr</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D21099">Removed
+ gzip'ed a.out support</a></li>
+
+ <li><a href="https://reviews.freebsd.org/D21072">Removed ArmvX
+ elf_trampoline.c</a></li>
+ </ul>
+
+ </body>
+
+ </project>
+
+ <project cat='kern'>
+ <title>Casueword(9) livelock</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The Compare-And-Swap (CAS) is one of the fundamental
+ building blocks
+ for hardware-assisted atomic read/modify/write operations.
+ Some
+ architectures support it directly, for instance x86 and
+ sparc. Others
+ provide different building blocks, usually the pair of
+ Load
+ Linked/Store Conditional instructions (ll/sc) which can be
+ used to construct
+ CAS or other atomic operations like Fetch-And-Add or any
+ atomic
+ arithmetic ops using plain arithmetic instructions. An
+ example is the
+ LDXR/STXR pair on AArch64.</p>
+
+ <p>The ll/sc operation is performed by first using the load
+ linked
+ instruction to load a value from memory and simultaneously
+ mark the
+ cache line for exclusive access. The value is then updated
+ by the
+ store conditional instruction, but only if there were not
+ any writes to
+ the marked cache line. Any write by another CPU makes the
+ store
+ instruction fail. So typically atomic primitives on ll/sc
+ architectures retry the whole operation if only store
+ failed, because
+ it just means that this CPU either lost a race, or even
+ the failure
+ was spurious. This is so called strong version of CAS and
+ atomics.
+ If primitive returns failure instead, the CAS variant is
+ called weak
+ by C standard.</p>
+
+ <p>For the FreeBSD threading library lock implementation,
+ when the fast path
+ mode in userspace was not possible, the kernel often needs
+ to do a CAS
+ operation on user memory location. In addition to all
+ guarantees of
+ normal CAS, it also must ensure the safety and tolerance
+ to paging.
+ In FreeBSD, the casueword32(9) primitive provides CAS on
+ usermode
+ 32bit words for kernel. Casueword32(9) was implemented as
+ strong CAS,
+ similarly to the mode of operation of hardware CAS
+ instructions on
+ x86.</p>
+
+ <p>Using the strong implementation for casueword may be
+ dangerous,
+ since the same address is potentially accessible to other,
+ potentially
+ malicious, threads in the same or other processes. If
+ such a thread constantly dirties the cache line used by a
+ ll/sc loop, it
+ could practically force the kernel-mode thread to remain
+ stuck in the loop
+ forever. Since the loop is tight, and it does not check
+ for signals,
+ the thread cannot be stopped or killed.</p>
+
+ <p>The solution is to make the casueword implementation weak,
+ which means that
+ the interface of the primitive must be changed to allow
+ notifying the
+ caller about spurious failures. Also, it is now the
+ caller's responsibility
+ to retry as appropriate.</p>
+
+ <p>The change to casueword was made for all architectures.
+ Even on x86,
+ the PSL.ZF value after the CMPXCHG instruction was
+ returned directly
+ for the new casueword. All two dozens uses of the
+ primitive, all
+ located in <i>kern_umtx.c</i>, were inspected
+ and retry added as needed.</p>
+
+ <p>As a somewhat related note, in-kernel
+ <tt>atomic_cmpset(9)</tt> operations are
+ strong, while <tt>atomic_fcmpset(9)</tt> should be weak,
+ unless broken by
+ a specific architecture. The general attitude seems to be
+ that retry is the
+ duty of the primitive's caller.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='kern'>
+ <title>Signals delivered on unhandled Page Faults</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>By necessity, handling of page faults is separated into
+ two pieces. The
+ first is the architecture-dependent low-level machine
+ exception handler,
+ and the second is the architecture-independent
+ <tt>vm_fault()</tt> function in
+ <i>sys/vm/vm_fault.c</i>.</p>
+
+ <p>Machine-dependent code for page faults typically consists
+ of three
+ components: a trampoline written in assembly which creates
+ the C execution
+ environment and gathers hardware-supplied data about page
+ fault reason, a
+ <tt>trap()</tt> function which is common C-level entry
+ point to dispatch all
+ exceptions processing, and the <tt>trap_pfault()</tt> C
+ function to specifically
+ handle page faults. <tt>trap_pfault()</tt> calls
+ <tt>vm_fault()</tt> when help from VM is
+ needed to resolve the situation.</p>
+
+ <p>If the fault was handled either by
+ <tt>trap()</tt>/<tt>trap_pfault()</tt> or
+ <tt>vm_fault()</tt>,
+ the faulting instruction is restarted. If fault cannot be
+ handled for
+ any reason, the next action depends on the mode in which
+ the fault occured.
+ If it was in kernel, and the kernel installed a helper,
+ then the helper is
+ called instead of returning to the faulting instruction.
+ Otherwise,
+ a kernel-mode page fault causes a panic.</p>
+
+ <p>If the unhandled fault occured in usermode, then all
+ Unixes send a
+ signal to the thread whose execution caused the exception.
+ POSIX (or
+ Single Unix Specification) lists several cases where a
+ signal should be
+ sent, and specifies the signal number and <tt>si_code</tt>
+ from siginfo that
+ must be supplied with the signal.</p>
+
+ <p>Unfortunately, FreeBSD was rather non-compliant in this
+ regard. A long
+ time ago, to improve compliance, we changed the signal
+ sent on access
+ to a page with permissions incompatible with the access
+ mode.
+ That caused multiple problems with garbage collection
+ (GC)-based runtimes
+ which incorporated knowledge of the FreeBSD quirks, so the
+ <tt>machdep.prot_fault_translation</tt> sysctl knob was
+ added. More cases of
+ incompatibility were identified recently.</p>
+
+ <p>Part of the problem is that code to calculate the signal
+ and <tt>si_code</tt> from
+ the Mach error returned by <tt>vm_fault()</tt> was located
+ in <tt>trap_pfault()</tt>. In
+ other words, each architecture did that on its own, with a
+ specific set
+ of bugs and non-compliance. Sometimes code even
+ mis-interpreted returned
+ Mach errors as <tt>errno</tt>.</p>
+
+ <p>A new helper function <tt>vm_fault_trap()</tt> was added,
+ that does several
+ things for trap handlers: it creates ktrace points for
+ faults, calls
+ <tt>vm_fault()</tt>, and then interprets the result in
+ terms of the user-visible
+ error condition, returning precalculated signal number and
+ <tt>si_code</tt> to
+ the caller. Now <tt>trap_pfault()</tt> only needs to
+ provide signal numbers
+ for truly machine-dependent errors. For amd64, an example
+ of such a
+ case is a protection key violation.</p>
+
+ <p>Besides compliance and bug fixes, we also provided some
+ refinements to
+ userspace about the reason of the delivered signal. For
+ instance, on
+ SIGBUS caused by copy-on-write failure due to exceeding
+ swap
+ reservation limit, we provide specific <tt>si_code</tt>
+ <tt>BUS_OOMERR</tt>.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='kern'>
+ <title>Randomized Top of Stack pointer</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>After the ASLR so useful addition, next in the series of
+ the
+ buzzword-compliant checkboxes is the stack addresses
+ randomization.</p>
+
+ <p>The main userspace thread stack on FreeBSD is
+ traditionally allocated
+ from the top of the user address space and grows down.
+ Besides the
+ initial pointer for the stack on userspace entry, this
+ area also
+ contains structures for program arguments and environment
+ (so called
+ strings), and aux vector data for ELF images.</p>
+
+ <p>Considering the goal of randomizing the addresses of
+ strings and main
+ thread initial frame, moving the main stack area in the
+ address space
+ is not feasible. It would cause significant ABI breakage,
+ invalidates
+ the knowledge already coded into many introspection tools,
+ and causes
+ unneeded additional fragmentation of the user address
+ space.</p>
+
+ <p>Instead a typical approach of adding a gap of randomized
+ size between
+ top of stack and a place for strings was used. It is done
+ in a way
+ which preserves the stack alignment requirement. Stack gap
+ is only
+ enabled if ASLR is enabled (not default) and stack gap
+ itself is
+ enabled (default if ASLR is enabled). Stack gap is
+ specified in
+ percentage of the total stack size that can be used for
+ maximum gap.</p>
+
+ <p>The main drawback of the gap approach was shortly
+ identified. Since
+ gap is cut from the normal stack area, attempts of the
+ programs to
+ reduce stack size using rlimit(RLIMIT_STACK) could cut the
+ active stack
+ region if new limit happens to be smaller than the gap.
+ E.g. on amd64
+ with its default 512M main thread stack, even one percent
+ of the max
+ gap gives approximately 5M of unused stack, that can blow
+ up the limit
+ of several KBs.</p>
+
+ <p>Typical reason for using rlimit(2) this way is for
+ programs that wire
+ all of its address space with mlockall(2), trying to
+ reduce potential
+ wired stack size to avoid exceeding RLIMIT_MEMLOCK.</p>
+
+ <p>First victim of that issue was ntpd, which resets the
+ stack limit
+ after start for a really small value. Currently the wiring
+ was removed
+ from ntpd, because apparently it does not make the
+ timekeeping better
+ by any means, contrary to popular belief.</p>
+
+ <p>My opinion is that the problem is more in the user
+ interface area than
+ in the gap approach itself. We should make it easy to
+ specify small
+ gap sizes, which cannot be done with integral percentage
+ interface.
+ So far I did not formulated a way to do this which I would
+ like, and
+ since nobody looked for a good solution because after ntpd
+ was fixed,
+ the severity of the issue seems very low.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='arch'>
+ <title>Broadcom ARM64 SoC support</title>
+
+ <contact>
+ <person>
+ <name>Michal Stanek</name>
+ <email>mst@semihalf.com</email>
+ </person>
+ <person>
+ <name>Kornel Duleba</name>
+ <email>mindal@semihalf.com</email>
+ </person>
+ <person>
+ <name>Marcin Wojtas</name>
+ <email>mw@semihalf.com</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The Semihalf team continued working on FreeBSD support for
+ the
+ <a
+ href="https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm58712/">Broadcom
+ BCM5871X SoC series</a></p>
+
+ <p>BCM5871X are quad-core 64-bit ARMv8 Cortex-A57
+ communication
+ processors targeted for networking applications such as
+ 10G routers,
+ gateways, control plane processing and NAS.</p>
+
+ <p>Completed since the last update:</p>
+
+ <ul>
+ <li>iProc PCIe root complex (internal and external buses):
+ fixes and improvements,</li>
+
+ <li>Crypto engine acceleration for IPsec offloading.</li>
+ </ul>
+
+ <p>
+ Todo:</p>
+
+ <ul>
+ <li>Upstreaming of work. This work is expected to be
+ submitted/merged
+ to HEAD in the Q4 of 2019.</li>
+ </ul>
+
+ </body>
+
+ <sponsor>
+ Juniper Networks, Inc
+ </sponsor>
+
+ </project>
+
+ <project cat='arch'>
+ <title>FreeBSD/powerpc Project</title>
+
+ <contact>
+ <person>
+ <name>Mark Linimon (ports)</name>
+ <email>linimon@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Justin Hibbits (src)</name>
+ <email>jhibbits@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Piotr Kubaj (ports)</name>
+ <email>pkubaj@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/powerpc/ports">Status of FreeBSD ports on PowerPC</url>
+ <url href="https://wiki.freebsd.org/powerpc/ports/PortsOnGcc">Status of FreeBSD ports on PowerPC built using gcc</url>
+ <url href="https://wiki.freebsd.org/powerpc/ports/PortsOnClang">Status of FreeBSD ports on PowerPC built using clang</url>
+ <url href="https://wiki.freebsd.org/powerpc/llvm-elfv2">Bringing LLVM to PowerPC64 target, using OpenPower ELF v2 ABI</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD/powerpc project continues to make great
+ strides. However,
+ as we discovered at BSDCan 2019, we have not done a great
+ job of letting
+ people know.</p>
+
+ <p>Key points:</p>
+
+ <ul>
+ <li>powerpc64 src on recent hardware has been
+ production-quality for over
+ a year now.</li>
+ <li>powerpc64 ports has been developer-quality for over 18
+ months now.</li>
+ </ul>
+
+ <p>
+ The main targeted platforms:</p>
+
+ <ul>
+ <li>powerpc64 on IBM POWER8 and POWER9 chips (the most recent
+ available).
+ This is the primary focus going forward. FreeBSD 12 is
+ required;
+ FreeBSD 13 is recommended.</li>
+ <li>powerpc64 on older Apple Power Macs, on a continuing but
+ secondary
+ basis. Any FreeBSD version should work.</li>
+ <li>powerpc64 on x5000. However, this is still developer-only
+ quality.
+ FreeBSD 13 is recommended.</li>
+ <li>powerpcspe on Amiga A1222. However, this is still
+ developer-only quality.
+ FreeBSD 13 is recommended.</li>
+ </ul>
+
+ <p>
+ The software status:</p>
+
+ <ul>
+ <li>powerpc*/12 and earlier still remain on the antiquated
+ gcc4.2.1 in
+ base.</li>
+ <li>powerpc*/13 will soon be switched to llvm90 in base. A
+ great deal
+ of work has been undertaken to ensure as few regressions
+ as possible.
+ Once that switch has occurred (see llvm-elfv2 link above),
+ powerpc*/13
+ support on gcc4.2.1 will no longer be a priority.</li>
+ <li>FreeBSD.org package sets are available for powerpc64/12
+ (quarterly)
+ and powerpc64/13 (default) through the usual method.</li>
+ <li>Firefox works on powerpc64 using experimental (not-yet
+ committed) patches,</li>
+ <li>As of the most recent package build on powerpc64/13 (still
+ gcc4.2.1),
+ the following statistics apply:
+ <table class="tblbasic">
+ <tr><th> Queued </th><th> Built </th><th> Failed </th><th> Skipped </th><th> Ignored </th></tr>
+ <tr><td> 33306 </td><td> 30514 </td><td> 245 </td><td> 1686 </td><td> 861 </td></tr>
+ </table>
+ </li>
+ <li>More ports fixes are being committed every day.</li>
+ </ul>
+
+ <p>
+ Also, Piotr would like to thank the FreeBSD Foundation for
+ funding
+ his personal Talos, and Raptor (via its IntegriCloud
+ subsidiary) for
+ loaning a server on which talos.anongoth.pl runs.</p>
+
+ <p>The team would like to thank IBM for the loan of two
+ POWER8 machines,
+ and Oregon State University (OSU) for providing the
+ hosting. As well,
+ we would like to thank the clusteradm team for keeping the
+ Tyan POWER8
+ machines online that are hosted at <a
+ href="https://www.nyi.net">NYI</a>.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='arch'>
+ <title>NXP ARM64 SoC support</title>
+
+ <contact>
+ <person>
+ <name>Marcin Wojtas</name>
+ <email>mw@semihalf.com</email>
+ </person>
+ <person>
+ <name>Artur Rojek</name>
+ <email>ar@semihalf.com</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The Semihalf team initiated working on FreeBSD support for
+ the
+ <a
+ href="https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/qoriq-layerscape-arm-processors/qoriq-layerscape-1046a-and-1026a-multicore-communications-processors:LS1046A">NXP
+ LS1046A SoC</a></p>
+
+ <p>LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors
+ with
+ integrated packet processing acceleration and high speed
+ peripherals
+ including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0
+ for a wide
+ range of networking, storage, security and industrial
+ applications.</p>
+
+ <p>Completed since the last update:</p>
+
+ <ul>
+ <li>DPAA Network interface support</li>
+
+ <li>SD/MMC</li>
+
+ <li>USB3.0</li>
+
+ <li>I2C</li>
+
+ <li>GPIO</li>
+ </ul>
+
+ <p>
+ In progress:</p>
+
+ <ul>
+ <li>QSPI</li>
+
+ <li>Network performance improvements</li>
+ </ul>
+
+ <p>
+ Todo:</p>
+
+ <ul>
+ <li>Upstreaming of developed features. This work is expected
+ to
+ be submitted/merged to HEAD in the Q4 of 2019.</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ Alstom Group
+ </sponsor>
+
+ </project>
+
+ <project cat='arch'>
+ <title>FreeBSD support for the forthcoming Arm Morello CPU, SoC, and board</title>
+
+ <contact>
+ <person>
+ <name>Robert Watson</name>
+ <email>rwatson@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Andrew Turner</name>
+ <email>andrew@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Brooks Davis</name>
+ <email>brooks@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>In September 2019, Arm announced Morello, an experimental
+ multicore superscalar
+ ARMv8-A CPU, SoC, and prototype board extended to
+ implement the CHERI
+ protection model. Morello will become available in 2021.
+ More details can be
+ found in
+ <a
+ href="https://www.arm.com/blogs/blueprint/digital-security-by-design">Arm's
+ blog</a>, a
+ <a
+ href="https://www.lightbluetouchpaper.org/2019/10/18/ukri-digital-security-by-design-a-190m-research-programme-around-arms-morello-an-experimental-armv8-a-cpu-soc-and-board-with-cheri-support/">Light
+ Blue Touchpaper blog</a>,
+ and the main
+ <a
+ href="https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/">CHERI
+ website</a>.</p>
+
+ <p>We have updated CheriBSD, a CHERI-adapted version of
+ FreeBSD originally
+ targeted at the MIPS-based SRI/Cambridge CHERI processor
+ prototype, to support
+ the current draft architecture. This includes full
+ userspace spatial and
+ referential memory safety
+
+ <a href="https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf">CheriABI</a>,
+ as well as backwards compatibility to support running
+ existing ARMv8-A
+ userspace binaries.</p>
+
+ <p>We will continue to update CheriBSD/Morello as the ISA is
+ finalised. Will also
+ closely track the public CheriBSD/MIPS trunk, picking up
+ new software features
+ utilizing CHERI as they mature, as well as to pick up
+ changes from the baseline
+ FreeBSD development trunk.</p>
+
+ <p>We currently anticipate releasing CheriBSD/Morello as open
+ source once the ISA
+ and toolchain are published in 2020.</p>
+
+ <p>Sponsors: DARPA, AFRL</p>
+
+ </body>
+
+ </project>
+
+ <project cat='ports'>
+ <title>Ports Collection</title>
+
+ <contact>
+ <person>
+ <name>René Ladan</name>
+ <email>portmgr-secretary@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>FreeBSD Ports Management Team</name>
+ <email>portmgr@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.FreeBSD.org/ports/">About FreeBSD Ports</url>
+ <url href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">Contributing to Ports</url>
+ <url href="http://portsmon.freebsd.org/index.html">FreeBSD Ports Monitoring</url>
+ <url href="https://www.freebsd.org/portmgr/index.html">Ports Management Team</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD Ports Management Team, tasked with overseeing
+ the Ports Tree and
+ its committers, reports that the following events happened
+ during 2019Q3:</p>
+
+ <p>The number of ports grew to just under 38,000 during the
+ last quarter. We have
+ just over 2,000 open ports PRs, of which 400 are
+ unassigned. In this period,
+ 169 committers made 7,340 commits to HEAD and 561 commits
+ to the quarterly
+ branch. This shows that the trend of last quarter of
+ increased activity is
+ continuing.</p>
+
+ <p>During the last quarter, we welcomed Santhosh Raju (fox@)
+ and Dmitri Goutnik
+ (dmgk@) to the team, and said goodbye to gabor@. During
+ the last quarter,
+ feld@ decided to step down from the portmgr@ and
+ ports-secteam@ teams. We
+ would like to thank them for their past services.</p>
+
+ <p>In the last three months, bapt@ put on his engineering hat
+ and released a new
+ version of pkg (1.12), added support for overlays to the
+ Ports Tree, fixed
+ two Make targets (deinstall-depends and reinstall), and
+ cleaned up
+ bsd.sites.mk.</p>
+
+ <p>On the infrastructure side, USES=pure became obsolete and
+ has therefore been
+ removed, and two new USES, xorg and xorg-cat have been
+ added and replace the
+ old bsd.xorg.mk. Two new keywords, ldconfig and
+ ldconfig-linux, were added to
+ simplify formatting of package lists.</p>
+
+ <p>A number of default versions changed: Lazarus to 2.0.4,
+ Linux to CentOS 7,
+ LLVM to 9.0, Perl to 5.30, PostgreSQL to 11, and Ruby to
+ 2.6. Of the big
+ user-visible ports, Firefox got updated to 69.0.1,
+ Firefox-esr to 68.1.0,
+ Chromium to 76.0.3809.132, and Xfce to 4.14.</p>
+
+ <p>During the last quarter, antoine@ ran 48 exp-runs to test
+ package updates, test
+ updating bsd.java.mk, test the new ldconfig and
+ ldconfig-linux keywords, test
+ default version updates, test the new xorg and xorg-cat
+ USES, test base
+ updates, and test various improvements to Go and Ruby.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='ports'>
+ <title>FreshPorts</title>
+
+ <contact>
+ <person>
+ <name>Dan Langille</name>
+ <email>dvl@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.FreshPorts.org/">FreshPorts</url>
+ <url href="https://github.com/FreshPorts/git_proc_commit">git_proc_commit code</url>
+ <url href="https://news.freshports.org/2019/09/03/things-you-didnt-know-freshports-can-do/">Things you didn’t know FreshPorts can do</url>
+ </links>
+
+ <body>
+ <p>FreshPorts consolidates commits into an easy-to-follow
+ format so you can track changes to your favorite ports.
+ It also processes src, doc, and www commit. FreshPorts
+ parses
+ incoming emails and refreshes the database with what it
+ finds.</p>
+
+ <p>In early September I started looking at how FreshPorts
+ could use a git repository for processing commits. The
+ result was <a
+ href="https://news.freshports.org/2019/09/02/git-and-freshports/">an
+ approach</a> for identifying new commits and
+ for iterating through them.</p>
+
+ <p>The next idea was <a
+ href="https://news.freshports.org/2019/09/18/moving-towards-commit-hooks/">commit
+ hooks</a> but the most interesting
+ bit of that exercise was commit iteration.</p>
+
+ <p>At the EuroBSDCon 2019 FreeBSD Developer summit, I wrote
+ up a small requirements section and then received great
+ help from two sources:</p>
+
+ <ul>
+ <li>Jan-Piet MENS recommended a <a
+ href="https://www.freshports.org/devel/py-gitpython/">Python
+ library</a> and
+ it turned out to be great</li>
+ <li>Sergey Kozlov wrote Python code to create xml using
+ that Python library</li>
+ </ul>
+
+ <p>
+ On the trip home, I was able to get the code to parse
+ a git commit into XML and loaded into a FreshPorts
+ database.</p>
+
+ <p>Returning home from the conference, I created a new
+ FreshPorts instance for processing git based on the above.
+ The website has needed no changes related to git.</p>
+
+ <p>The remaining tasks:</p>
+
+ <ul>
+ <li>automate the script (git pull, etc)</li>
+
+ <li>detect new commits (for later iteration)</li>
+
+ <li>design a light-weight git hook</li>
+ </ul>
+
+ <p>
+ Event: EuroBSDCon 2019 Hackathon
+ Sponsored by: Intel Corporation (work done by Sergey
+ Kozlov)</p>
+
+ </body>
+
+ </project>
+
+ <project cat='ports'>
+ <title>KDE on FreeBSD</title>
+
+ <contact>
+ <person>
+ <name>Adriaan de Groot</name>
+ <email>kde@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://freebsd.kde.org/">KDE FreeBSD</url>
+ <url href="https://community.kde.org/FreeBSD">KDE Community FreeBSD</url>
+ </links>
+
+ <body>
+ <p>The <i>KDE on FreeBSD</i> project packages the
+ software produced by
+ the KDE Community for FreeBSD. The software includes a
+ full desktop environment, the art application
+ <a href="https://kdenlive.org">https://kdenlive.org</a>
+ and hundreds of other applications that can be used on
+ any FreeBSD desktop machine.</p>
+
+ <p>Along with KDE itself, the team maintains the Qt
+ libraries, the CMake
+ build system, and a handful of other C++ libraries used in
+ the KDE stack.</p>
+
+ <p>The upstream releases KDE Frameworks (libraries) on a
+ monthly
+ cycle, KDE Plasma (the desktop environment) quarterly and
+ a collection of KDE Applications (usable everywhere) twice
+ a year.
+ The KDE on FreeBSD team chased a dozen updates to these
+ components
+ so that FreeBSD remains one of the most up-to-date systems
+ with KDE software (and Qt).</p>
+
+ <p>A large (and possibly breaking, still needs more
+ investigation)
+ change came with the release to KDE's Digikam 6.3.0, which
+ stopped
+ using its previous plugins system (the "old" plugins are
+ still used
+ by other KDE software).</p>
+
+ <p>A new entry in the net-im category was added for Ruqola, a
+ Rocket.chat client for rich instant-messaging.</p>
+
+ <p>CMake was updated twice. This forces the rebuild of
+ several thousand
+ C++-based ports. The KDE on FreeBSD team then fixes those
+ ports,
+ regardless of whether the error is in the CMake update, or
+ in
+ the upstream code. These updates tend to take a large
+ amount of effort,
+ since they touch unfamiliar (and often very-very-legacy)
+ code.</p>
+
+ <p>The <a
+ href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=New&amp;bug_status=Open&amp;bug_status=In%20Progress&amp;bug_status=UNCONFIRMED&amp;email1=kde%40FreeBSD.org&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;f0=OP&amp;f1=OP&amp;f2=product&amp;f3=component&amp;f4=alias&amp;f5=short_desc&amp;f7=CP&amp;f8=CP&amp;f9=assigned_to&amp;j1=OR&amp;j_top=OR&amp;o2=substring&amp;o3=substring&amp;o4=substring&amp;o5=substring&amp;o9=substring&amp;query_format=advanced&amp;v2=kde%40&amp;v3=kde%40&amp;v4=kde%40&amp;v5=kde%40&amp;v9=kde%40&amp;human=1">open
+ bugs list</a>
+ grew to 24 this quarter.
+ It tends to hover around 20 items as new things come in
+ and old ones are resolved. We welcome detailed bug reports
+ and patches. KDE packaging updates are prepared in
+ a <a
+ href="https://github.com/freebsd/freebsd-ports-kde/">copy
+ of the ports repository</a>
+ on GitHub and then merged in SVN. We welcome pull requests
+ there as well.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='ports'>
+ <title>Java on FreeBSD</title>
+
+ <contact>
+ <person>
+ <name>Greg Lewis</name>
+ <email>glewis@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/freebsd/openjdk-jdk11u">OpenJDK 11 repository at FreeBSD GitHub</url>
+ </links>
+
+ <body>
+ <p>Over the last few quarters there has been considerable
+ work in improving
+ support for Java 11 and higher, with some work being
+ backported to Java 8.</p>
+
+ <p>Starting with the initial release in March on amd64, over
+ the
+ intervening months FreeBSD support was added for features
+ such as:</p>
+
+ <ul>
+ <li>Java Flight Recorder</li>
+
+ <li>HotSpot Serviceability Agent</li>
+
+ <li>HotSpot Debugger</li>
+
+ <li>DTrace</li>
+
+ <li>Javac Server</li>
+
+ <li>Java Sound</li>
+
+ <li>SCTP</li>
+ </ul>
+
+ <p>
+ In addition, support for the aarch64, i386 and powerpc64
+ architectures
+ was also added.</p>
+
+ <p>With most features supported, attention turned to
+ compliance, using the
+ internal JDK test suite as a method of measuring this.
+ Most work during
+ the third quarter has focused on this, with test failures
+ dropping from
+ 50+ failures to only 2 tier1 test failures (which don't
+ appear to impact
+ functionality at all). Some significant fixes include:</p>
+
+ <ul>
+ <li>A stack overflow crash</li>
+
+ <li>Errors in external process handling</li>
+
+ <li>The unpack200 utility (on little endian systems)</li>
+
+ <li>HotSpot Debugger functionality such as thread enumeration</li>
+
+ <li>Networking functionality</li>
+ </ul>
+
+ <p>
+ Finally, this work has been forward ported to Java 12 and
+ 13, with FreeBSD
+ gaining support for these versions on or just after the
+ day of release.</p>
+
+ <p>Note that this work has been a collaboration with many
+ others. While there
+ are too many contributors to list here (please take a look
+ at the commit
+ history of the GitHub repository), I'd like to recognise
+ Kurt Miller of
+ OpenBSD for his tireless work as a co-collaborator on Java
+ for BSD through
+ many years.</p>
+
+ <p>I'm also grateful to the sponsorship of the FreeBSD
+ Foundation, which has
+ allowed me to focus on this work for Q3.</p>
+
+ </body>
+
+ <sponsor>
+ FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='ports'>
+ <title>XFCE 4.14 update</title>
+
+ <contact>
+ <person>
+ <name>Guido Falsi</name>
+ <email>xfce@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://xfce.org/about/news/?post=1565568000">XFCE 4.14 announce</url>
+ </links>
+
+ <body>
+ <p>On September 19th the XFCE desktop environment ports have
+ been updated
+ to the recently released XFCE 4.14 version.</p>
+
+ <p>These updates include upgrades of all the main XFCE
+ components to the
+ latest versions which have been migrated to GTK3, with few
+ exceptions.
+ Base components still require and link to GTK2 in addition
+ to GTK3 to
+ allow older GTK2 XFCE applications, for example panel
+ plugins, to keep
+ working.</p>
+
+ <p>Due to this change the gtk-xfce-engine theme is deprecated
+ since it only
+ supports GTK2. The XFCE metaport by default installs the
+ greybird theme,
+ but it is not enabled by default.</p>
+
+ <p>This new version also includes now it's own
+ xfce4-screensaver program
+ which is installed by default.</p>
+
+ <p>Finally the default Display Manager on which XFCE depends
+ has been
+ changed to LightDM.</p>
+
+ <p>Some regressions were reported in bugzilla. In particular
+ the one
+ affecting most users is a regression in the window
+ manager: on specific
+ graphic display hardware the window manager fails to
+ properly draw
+ window decorations, which appear black and blocky on
+ affected systems.</p>
+
+ <p>This problem has also been reported in the upstream bug
+ tracker and a
+ solution is being sought.</p>
+
+ <p>If anyone is experiencing this display glitch and is able
+ to test,
+ please contact xfce@freebsd.org to help trying to figure
+ out a solution.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>ClonOS: virtualization platform on top of FreeBSD Operating System</title>
+
+ <contact>
+ <person>
+ <name>Oleg Ginzburg</name>
+ <email>olevole@olevole.ru</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://clonos.tekroutine.com/download.html">ClonOS 19.09</url>
+ <url href="https://www.bsdstore.ru/">CBSD</url>
+ </links>
+
+ <body>
+ <h3>What is ClonOS?</h3>
+
+ <p>ClonOS is a turnkey open-source platform based on FreeBSD
+ and the CBSD
+ framework. ClonOS offers a complete web UI for an easy
+ control, deployment
+ and management of FreeBSD jails containers and bhyve/Xen
+ hypervisor virtual
+ environments.</p>
+
+ <p>ClonOS is currently the only available platforms which
+ allow both Xen and bhyve
+ hypervisors to coexist on the same host. Since ClonOS is a
+ FreeBSD-based
+ platform, it has the ability to create and manage jails
+ natively, allowing
+ you to run FreeBSD applications without losing
+ performance.</p>
+
+ <h3>ClonOS/CBSD 2019Q3 Status Report</h3>
+
+ <ul>
+ <li>Added support for cloud-init (Linux/BSD VMs) and
+ cloudbase-init
+ (Windows VMs). It gives the ability to use FreeBSD as IaaS
+ platform
+ for instant deployment and usage of virtual machines based
+ on bhyve
+ hypervisor.</li>
+
+ <li>Project started to use own cloud images for better
+ stability and
+ resiliency.</li>
+
+ <li>New mirrors in France, US and Canada were added for
+ distributing ISO/cloud-init images in addition to Russia,
+ Latvia and
+ Ukraine.</li>
+
+ <li>Now we're using Jenkins CI for testing regular ClonOS
+ builds:
+ <a
+ href="https://jenkins.ircdriven.net/job/Update%20clonos%20packages./">Update
+ clonos packages</a> (Thanks to Daniel Shafer)</li>
+
+ <li>New pkg repository was deployed to support ClonOS
+ installation
+ from packages (at this moment only FreeBSD-12 packages are
+ available)
+ <a
+ href="https://pkg.ircdriven.net/packages/12amd64-clonos/">ClonOS
+ package repo</a> (Thanks to Daniel Shafer)</li></ul>
+
+ <p>
+ Open issues and tasks:</p>
+
+ <ul>
+ <li>Volunteers, contributors and testers are urgently needed
+ to
+ distribute ClonOS on FreeBSD environments.</li>
+
+ <li>We'd like to expand our mirrors number geographically,
+ your help and contribution will be much appriciated.</li>
+
+ <li>We're urgently looking for hosting sponsorship for various
+ developing and testing activities.</li></ul>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>sysctlinfo</title>
+
+ <contact>
+ <person>
+ <name>Alfonso Sabato Siciliano</name>
+ <email>alfonso.siciliano@email.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://gitlab.com/alfix/sysctlinfo">gitlab.com/alfix/sysctlinfo</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD kernel maintains a Management Information Base
+ (MIB) where a
+ component (object) represents a parameter of the system.
+ The <i>sysctl</i> system
+ call explores the MIB to find an object by its Object
+ Identifier (OID) and
+ calls its handler to get or set the value of the
+ parameter. It is often
+ necessary to find an object not to call its handler but to
+ get its info
+ (description, type, name, next object, etc.), so the
+ kernel provides an
+ undocumented interface implemented in kern_sysctl.c.</p>
+
+ <p>sysctlinfo is a new interface to explore the sysctl MIB
+ and to pass the info
+ of an object to the userland. The project provides: a
+ README, a manual, helper
+ macros, examples, tests and converted tools.</p>
+
+ <p>Primarily sysctlinfo provides a new set of sysctl nodes
+ (corresponding to the
+ kernel interface) to handle an object up to CTL_MAXNAME
+ levels:
+ sysctl.entryfakename, sysctl.entrydesc, sysctl.entrylabel,
+ sysctl.entrykind,
+ sysctl.entryfmt and sysctl.entrynextleaf. Moreover new
+ features have been
+ implemented: the support for the capability mode,
+ sysctl.entryname,
+ sysctl.entryidbyname and sysctl.entrynextnode. To get all
+ the info about an
+ object the kernel needs to find it many times, then the
+ new
+ sysctl.entryallinfo* nodes were written, they are 30%
+ more efficient. Finally,
+ *byname nodes were added: they search the object by its
+ name avoiding to call
+ sysctl.name2oid (or similar) to explore the MIB just to
+ find the corresponding
+ OID.</p>
+
+ <p>sysctlinfo can be installed via <i>sysutils/sysctlinfo-kmod</i>
+ or by applying the
+ <i>sysctlinfo.diff</i> patch (more efficient than the module
+ because uses a shared
+ lock). The interface is used by <i>deskutils/sysctlview
+ 1.5</i>,
+ <i>sysutils/nsysctl 1.2</i> and the converted version of
+ sysctl(8), sysctlbyname(3),
+ sysctlnametomib(3), they should be used to get the value
+ of an object with 23/24
+ levels or if some level-name has only the '\0' character.
+ In the future a new
+ <i>byname</i> node will be added to allow sysctlbyname() to
+ manage a CTLTYPE_NODE with
+ a no-NULL handler, example
+ sysctlbyname("kern.proc.pid.\&lt;pid\&gt;").</p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>Nomad pot driver - Orchestrating jails via nomad</title>
+
+ <contact>
+ <person>
+ <name>Luca Pizzamiglio</name>
+ <email>pizzamig@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Esteban Barrios</name>
+ <email>esteban.barrios@trivago.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/trivago/nomad-pot-driver">Nomad pot driver</url>
+ <url href="https://github.com/pizzamig/pot">Pot project</url>
+ </links>
+
+ <body>
+ <p>An experimental project has started to provide jail
+ orchestration
+ based on <tt>nomad</tt> and the jail framework
+ <tt>pot</tt>, similarly to how
+ orchestration works with docker.</p>
+
+ <p>This model allows us to split the jail creation and the
+ jail deployment.
+ Jail images can be created and exported using the
+ <tt>pot</tt> framework.
+ The images can be deployed and orchestrated using
+ <tt>nomad</tt>.
+ A driver has been developed to allow <tt>nomad</tt> to
+ interact with <tt>pot</tt>.</p>
+
+ <p>One of the goals of this project is to use non-persistent
+ jails as
+ containers, allowing us to:</p>
+
+ <ul>
+ <li>define containers similar to Docker (but not identical,
+ because
+ the underlaying OS is different)</li>
+
+ <li>identify potential missing features in FreeBSD to support
+ such a computational model</li>
+ </ul>
+
+ <p>
+ In the next quarter, we will launch the first service
+ based on this
+ project.</p>
+
+ <p>Next steps are:</p>
+
+ <ul>
+ <li>provide more guides and howtos</li>
+
+ <li>improve stability, extending the tests suite</li>
+
+ <li>improving tooling to create/manage images</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ trivago N.V.
+ </sponsor>
+
+ </project>
+
+ <project cat='third'>
+ <title>ENA FreeBSD Driver Update</title>
+
+ <contact>
+ <person>
+ <name>Michal Krawczyk</name>
+ <email>mk@semihalf.com</email>
+ </person>
+ <person>
+ <name>Maciej Bielski</name>
+ <email>mba@semihalf.com</email>
+ </person>
+ <person>
+ <name>Marcin Wojtas</name>
+ <email>mw@semihalf.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README">ENA README</url>
+ </links>
+
+ <body>
+ <p>ENA (Elastic Network Adapter) is the smart NIC available
+ in the
+ virtualized environment of Amazon Web Services (AWS). The
+ ENA
+ driver supports multiple transmit and receive queues and
+ can handle
+ up to 100 Gb/s of network traffic, depending on the
+ instance type
+ on which it is used.</p>
+
+ <p>ENAv2 has been under development for FreeBSD, similar to
+ Linux
+ and DPDK. Since the last update internal review and
+ improvements
+ of the patches were done, followed by validation on
+ various AWS
+ instances.</p>
+
+ <p>Completed since the last update:</p>
+
+ <ul>
+ <li>Verification and review of the NETMAP support</li>
+
+ <li>Mapping of the memory as WC on A1 instances in order to
+ enable LLQ mode</li>
+ </ul>
+
+ <p>
+ Todo:</p>
+
+ <ul>
+ <li>Upstream of NETMAP support</li>
+
+ <li>Upstream of the fix for LLQ mode on A1 instances</li>
+ </ul>
+
+ <p></p>
+
+ <sponsor>
+ Amazon.com Inc
+ </sponsor>
+
+ </body>
+
+ </project>
+
+</report>

File Metadata

Mime Type
text/plain
Expires
Fri, Apr 10, 10:41 PM (8 h, 28 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
31250757
Default Alt Text
D22323.diff (94 KB)

Event Timeline