Page MenuHomeFreeBSD
Files F163349675

D20446.id57998.diff
No OneTemporary
Actions

D20446.id57998.diff
View Options

Index: en_US.ISO8859-1/htdocs/news/status/Makefile
===================================================================
--- en_US.ISO8859-1/htdocs/news/status/Makefile
+++ en_US.ISO8859-1/htdocs/news/status/Makefile
@@ -82,6 +82,7 @@
XMLDOCS+= report-2017-10-2017-12
XMLDOCS+= report-2018-01-2018-09
XMLDOCS+= report-2018-09-2018-12
+XMLDOCS+= report-2019-01-2019-03
XSLT.DEFAULT= report.xsl
Index: en_US.ISO8859-1/htdocs/news/status/report-2019-01-2019-03.xml
===================================================================
--- /dev/null
+++ en_US.ISO8859-1/htdocs/news/status/report-2019-01-2019-03.xml
@@ -0,0 +1,2537 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
+ Status Report//EN"
+ "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
+
+<!-- $FreeBSD: head/en_US.ISO8859-1/htdocs/news/status/report-template.xml 51132 2017-10-19 01:38:11Z bjk $ -->
+<!-- This file was generated with https://github.com/trasz/md2docbook -->
+<!--
+ Variables to replace:
+ %%START%% - report month start
+ %%STOP%% - report month end
+ %%YEAR%% - report year
+ %%NUM%% - report issue (first, second, third, fourth)
+ %%STARTNEXT%% - report month start
+ %%STOPNEXT%% - report month end
+ %%YEARNEXT%% - next report due year (if different than %%YEAR%%)
+ %%DUENEXT%% - next report due date (i.e., June 6)
+-->
+
+<report>
+ <date>
+ <month>%%START%%-%%STOP%%</month>
+
+ <year>%%YEAR%%</year>
+ </date>
+
+ <section>
+ <title>Introduction</title>
+
+ <p><strong>This is a draft of the %%START%%&ndash;%%STOP%% %%YEAR%%
+ status report. Please check back after it is finalized, and
+ an announcement email is sent to the &os;-Announce mailing
+ list.</strong></p>
+
+ <?ignore
+ <p>This report covers &os;-related projects between %%START%% and
+ %%STOP%% %%YEAR%%. This is the %%NUM%% of four reports planned for
+ %%YEAR%%.</p>
+
+ <p>The %%NUM%% quarter of %%YEAR%% was another productive quarter for
+ the &os; project and community. [...]</p>
+
+ <p>Thanks to all the reporters for the excellent work!</p>
+
+ <p>The deadline for submissions covering the period from %%STARTNEXT%%
+ to %%STOPNEXT%% %%YEARNEXT%% is %%DUENEXT%%, %%YEARNEXT%%.</p>
+ ?>
+ </section>
+
+ <category>
+ <name>team</name>
+
+ <description>&os; Team Reports</description>
+
+ <p>Entries from the various official and semi-official teams,
+ as found in the <a href="&enbase;/administration.html">Administration
+ Page</a>.</p>
+ </category>
+
+ <category>
+ <name>proj</name>
+
+ <description>Projects</description>
+
+ <p>Projects that span multiple categories, from the kernel and userspace
+ to the Ports Collection or external projects.</p>
+ </category>
+
+ <category>
+ <name>kern</name>
+
+ <description>Kernel</description>
+
+ <p>Updates to kernel subsystems/features, driver support,
+ filesystems, and more.</p>
+ </category>
+
+ <category>
+ <name>arch</name>
+
+ <description>Architectures</description>
+
+ <p>Updating platform-specific features and bringing in support
+ for new hardware platforms.</p>.
+ </category>
+
+ <category>
+ <name>bin</name>
+
+ <description>Userland Programs</description>
+
+ <p>Changes affecting the base system and programs in it.</p>
+ </category>
+
+ <category>
+ <name>ports</name>
+
+ <description>Ports</description>
+
+ <p>Changes affecting the Ports Collection, whether sweeping
+ changes that touch most of the tree, or individual ports
+ themselves.</p>
+ </category>
+
+ <category>
+ <name>doc</name>
+
+ <description>Documentation</description>
+
+ <p>Noteworthy changes in the documentation tree or new external
+ books/documents.</p>
+ </category>
+
+ <category>
+ <name>misc</name>
+
+ <description>Miscellaneous</description>
+
+ <p>Objects that defy categorization.</p>
+ </category>
+
+ <category>
+ <name>third</name>
+
+ <description>Third-Party Projects</description>
+
+ <p>Many projects build upon &os; or incorporate components of
+ &os; into their project. As these projects may be of interest
+ to the broader &os; community, we sometimes include brief
+ updates submitted by these projects in our quarterly report.
+ The &os; project makes no representation as to the accuracy or
+ veracity of any claims in these submissions.</p>
+ </category>
+
+ <project cat='team'>
+ <title>FreeBSD Release Engineering Team</title>
+
+ <contact>
+ <person>
+ <name>FreeBSD Release Engineering Team</name>
+ <email>re@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.freebsd.org/releases/11.3R/schedule.html">FreeBSD 11.3-RELEASE schedule</url>
+ <url href="https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/">FreeBSD development snapshots</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD Release Engineering Team is responsible for
+ setting and
+ publishing release schedules for official project releases
+ of
+ FreeBSD, announcing code freezes and maintaining the
+ respective
+ branches, among other things.</p>
+
+ <p>During the first quarter of 2019, the FreeBSD Release
+ Engineering team
+ published the initial schedule for the upcoming the
+ 11.3-RELEASE.</p>
+
+ <p>FreeBSD 11.3-RELEASE will be the fourth release from the
+ <tt>stable/11</tt>
+ branch, building on the stability and reliability of
+ 11.2-RELEASE.
+ FreeBSD 11.3-RELEASE is currently targed for release in
+ early July, 2019.</p>
+
+ <p>Additionally throughout the quarter, several development
+ snapshots builds
+ were released for the <tt>head</tt>, <tt>stable/12</tt>,
+ and <tt>stable/11</tt> branches.</p>
+
+ <p>Much of this work was sponsored by the FreeBSD Foundation.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>Ports Collection</title>
+
+ <contact>
+ <person>
+ <name>René Ladan</name>
+ <email>portmgr-secretary@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>FreeBSD Ports Management Team</name>
+ <email>portmgr@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.FreeBSD.org/ports/">About FreeBSD Ports</url>
+ <url href="https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html">Contributing to Ports</url>
+ <url href="http://portsmon.freebsd.org/index.html">FreeBSD Ports Monitoring</url>
+ <url href="https://www.freebsd.org/portmgr/index.html">Ports Management Team">Ports Management Team</url>
+ </links>
+
+ <body>
+ <p>As always, below is a summary of what happened in the
+ Ports Tree during the
+ last quarter.</p>
+
+ <p>During 2019q1, the number of ports dropped slightly to
+ just over 32,500. At
+ the end of the quarter, we had 2092 open port PRs. The
+ last quarter saw 8205
+ commits from 167 committers. So more PRs were closed and
+ more commits were
+ made than in 2018q4.</p>
+
+ <p>During the last quarter, we welcomed Kai Knoblich (kai@)
+ and said goodbye to
+ Matthew Rezny (rezny@).</p>
+
+ <p>On the infrastructure side, two new USES were introduced
+ (azurepy and sdl) and
+ USES=gecko was removed. The default versions of Lazarus
+ and LLVM were bumped
+ to 2.0.0 and 8.0 respectively. Some big port frameworks
+ that were end-of-life
+ were removed: PHP 5.6, Postgresql 9.3, Qt4, WebKit-Gtk and
+ XPI. Firefox was
+ updated to 66.0.2, Firefox-ESR to 60.6.1, and Chromium was
+ updated to
+ 72.0.3626.121.</p>
+
+ <p>During the last quarter, antoine@ ran 30 exp-runs for
+ package updates, moving
+ from GNU ld to LLVM ld, and switching clang to DWARF4.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>FreeBSD Core Team</title>
+
+ <contact>
+ <person>
+ <name>FreeBSD Core Team</name>
+ <email>core@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD Core Team is the governing body of FreeBSD.</p>
+
+ <p>Core initiated a <tt>Release Engineering Charter
+ Modernization</tt> working
+ group. The purpose of the working group is to present (to
+ Core) a
+ modernized version of the <tt>Release Engineering
+ Charter</tt> and a first
+ version of a new <tt>Release Engineering Team Operations
+ Plan</tt>. The
+ group hopes to complete its goals and dissolve by
+ 2019-06-30.</p>
+
+ <p>The Core Team invites all members of the FreeBSD community
+ to
+ complete the <tt>2019 FreeBSD Community Survey</tt>.</p>
+
+ <p>https://www.research.net/r/freebsd2019</p>
+
+ <p>The purpose of the survey is to collect quantitative data
+ from the
+ public in order to help guide the project's priorities and
+ efforts.
+ It will remain open for 17 days and close at midnight May
+ 13 UTC
+ (Monday 5pm PDT).
+ (Editor's note: Survey has finished)</p>
+
+ <p>Core voted to approve source commit bits for Johannes
+ Lundberg
+ (johalun@) and Mitchell Horne (mhorne@) and associate
+ membership
+ for Philip Jocks. Core also voted to revoke Michael
+ Dexter's
+ documentation bit.</p>
+
+ <p>After a long lapse of not closing idle source commit bits,
+ core has
+ taken in the commit bit for these developers. We thank
+ each for
+ contributing to the project as a source committer.</p>
+
+ <ul>
+ <li>Alfred Perlstein (alfred@)</li>
+
+ <li>Eric Badger (badger@)</li>
+
+ <li>Daniel Eischen (deischen@)</li>
+
+ <li>Ermal Luçi (eri@)</li>
+
+ <li>Tony Finch (fanf@)</li>
+
+ <li>Justin T. Gibbs (gibbs@)</li>
+
+ <li>Imre Vadász (ivadasz@)</li>
+
+ <li>Julio Merino (jmmv@)</li>
+
+ <li>John W. De Boskey (jwd@)</li>
+
+ <li>Kai Wang (kaiw@)</li>
+
+ <li>Luigi Rizzo (luigi@)</li>
+
+ <li>Neel Natu (neel@)</li>
+
+ <li>Craig Rodrigues (rodrigc@)</li>
+
+ <li>Stanislav Sedov (stas@)</li>
+
+ <li>Thomas Quinot (thomas@)</li>
+
+ <li>Andrew Thompson (thompsa@)</li>
+
+ <li>Pyun YongHyeon (yongari@)</li>
+
+ <li>Zbigniew Bodek (zbb@)</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>FreeBSD Foundation</title>
+
+ <contact>
+ <person>
+ <name>Deb Goodkin</name>
+ <email>deb@FreeBSDFoundation.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD Foundation is a 501(c)(3) non-profit
+ organization dedicated to
+ supporting and promoting the FreeBSD Project and community
+ worldwide.
+ Funding comes from individual and corporate donations and
+ is used to fund
+ and manage software development projects, conferences and
+ developer summits,
+ and provide travel grants to FreeBSD contributors.</p>
+
+ <p>The Foundation purchases and supports hardware to improve
+ and maintain
+ FreeBSD infrastructure and provides resources to improve
+ security,
+ quality assurance, and release engineering efforts;
+ publishes
+ marketing material to promote, educate, and advocate for
+ the FreeBSD Project;
+ facilitates collaboration between commercial vendors and
+ FreeBSD developers;
+ and finally, represents the FreeBSD Project in executing
+ contracts,
+ license agreements, and other legal arrangements that
+ require
+ a recognized legal entity.</p>
+
+ <p>Here are some highlights of what we did to help FreeBSD
+ last quarter:</p>
+
+ <p>We kicked off the year with an all-day board meeting in
+ Berkeley,
+ where FreeBSD began, to put together high-level plans for
+ 2019.
+ This included prioritizing technologies and features we
+ should support,
+ long-term planning for the next 2-5 years, and
+ philosophical discussions
+ on our purpose and goals.</p>
+
+ <p>Partnerships and Commercial User Support</p>
+
+ <p>We began the year by meeting with a few commercial users,
+ to help them
+ navigate working with the Project, and understanding how
+ they are using
+ FreeBSD. We're also in the process of setting up meetings
+ for Q2 and
+ throughout the rest of 2019. Because we're a 501(c)(3)
+ non-profit, we
+ don't directly support commercial users.
+ However, these meetings allow us to focus on facilitating
+ collaboration
+ with the community.</p>
+
+ <p>Fundraising Efforts</p>
+
+ <p>Our work is 100% funded by your donations. We kicked off
+ the year with many
+ individual and corporate donations, including donations
+ and commitments from
+ NetApp, Netflix, Intel, Tarsnap, Beckhoff Automation,
+ E-Card, VMware, and
+ Stormshield. We are working hard to get more commercial
+ users to give back
+ to help us continue our work supporting FreeBSD.
+ Please consider making a
+ <a
+ href="https://www.FreeBSDfoundation.org/donate/">donation</a>
+ to help us continue and increase our support for FreeBSD
+ at:
+ <a
+ href="https://www.FreeBSDfoundation.org/donate/">www.FreeBSDfoundation.org/donate/</a>.</p>
+
+ <p>We also have the Partnership Program, to provide more
+ benefits for our
+ larger commercial donors. Find out more information at
+
+ https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/
+ and share with your companies!</p>
+
+ <p>OS Improvements</p>
+
+ <p>The Foundation improves the FreeBSD operating system by
+ employing our
+ technical staff to maintain and improve critical kernel
+ subsystems,
+ add features and functionality, and fix problems. This
+ also includes funding
+ separate project grants like
+ the arm64 port, porting the blacklistd access control
+ daemon, and the
+ integration of VIMAGE support,
+ to make sure that FreeBSD remains a viable solution for
+ research, education,
+ computing, products and more.</p>
+
+ <p>Over the quarter there were 241 commits from nine
+ Foundation-sponsored staff
+ members and grant recipients.</p>
+
+ <p>We kicked off or continued the following projects last
+ quarter:</p>
+
+ <ul>
+ <li>FUSE file system kernel support (update and bug fixes)</li>
+
+ <li>Linuxulator testing and diagnostics improvements</li>
+
+ <li>SDIO and WiFi infrastructure improvements</li>
+
+ <li>x86-64 scalability and performance improvements</li>
+
+ <li>OpenZFS Online RAID-Z Expansion</li>
+ </ul>
+
+ <p>
+ Having software developers on staff has allowed us to jump
+ in and
+ work directly on projects to improve FreeBSD like:</p>
+
+ <ul>
+ <li>amd64 and i386 pmap improvements and bugfixes</li>
+
+ <li>address userland threading library issues</li>
+
+ <li>improve i386 support to keep the platform viable</li>
+
+ <li>improve FreeBSD on RISC-V</li>
+
+ <li>application of the Capsicum sandboxing framework</li>
+
+ <li>build system improvements and bug fixes</li>
+
+ <li>respond to reports of security issues</li>
+
+ <li>implement vulnerability mitigations</li>
+
+ <li>tool chain updates and improvements</li>
+
+ <li>adding kernel code coverage support for the
+ <a
+ href="https://github.com/google/syzkaller">Syzkaller</a>
+ coverage-guided system call
+ fuzzer</li>
+
+ <li>improved Syzkaller support for FreeBSD</li>
+
+ <li>improve the usability of <tt>freebsd-update</tt></li>
+
+ <li>improve network stack stability and address race
+ conditions</li>
+
+ <li>ensure FreeBSD provides userland interfaces required by
+ contemporary
+ applications</li>
+
+ <li>implement support for machine-dependent optimized
+ subroutines</li>
+
+ <li>update and correct documentation and manpages</li>
+
+ <li>DTrace bug fixes</li>
+
+ <li>update the FreeBSD Valgrind port and try to upstream the
+ changes</li>
+ </ul>
+
+ <p>
+ Continuous Integration and Quality Assurance</p>
+
+ <p>The Foundation provides a full-time staff member who is
+ working on improving
+ our automated testing, continuous integration, and overall
+ quality assurance
+ efforts.</p>
+
+ <p>During the first quarter of 2019, Foundation staff
+ continued improving the
+ project's CI infrastructure, working with contributors to
+ fix failing build
+ and test cases, and working with other teams in the
+ project for their
+ testing needs. In this quarter, we started publishing the
+ <a
+ href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">CI
+ weekly report</a>
+ on the freebsd-testing@ mailing list.</p>
+
+ <p>See the FreeBSD CI section of this report for more
+ information.</p>
+
+ <p>Release Engineering</p>
+
+ <p>The Foundation provides a full-time staff member to
+ oversee the
+ release engineering efforts. This has provided timely and
+ reliable releases
+ over the last five years.</p>
+
+ <p>During the first quarter of 2019, the FreeBSD Release
+ Engineering team
+ continued providing weekly development snapshots for
+ 13-CURRENT, 12-STABLE,
+ and 11-STABLE.</p>
+
+ <p>In addition, the Release Engineering team published the
+ schedule for the
+ upcoming 11.3-RELEASE cycle, the fourth release from the
+ stable/11 branch,
+ which builds on the stability and reliability of
+ 11.2-RELEASE.</p>
+
+ <p>The upcoming
+ <a
+ href="https://www.freebsd.org/releases/11.3R/schedule.html">11.3-RELEASE
+ schedule</a>
+ can be found at:
+ https://www.freebsd.org/releases/11.3R/schedule.html</p>
+
+ <p>FreeBSD 11.3 is currently targeted for final release in
+ early July 2019.</p>
+
+ <p>Please see the FreeBSD Release Engineering Team section of
+ this quarterly
+ status report for additional details surrounding the above
+ mentioned work.</p>
+
+ <p>Supporting FreeBSD Infrastructure</p>
+
+ <p>The Foundation provides hardware and support to improve
+ FreeBSD infrastructure. Last quarter, we continued
+ supporting FreeBSD hardware located
+ around the world.</p>
+
+ <p>FreeBSD Advocacy and Education</p>
+
+ <p>A large part of our efforts are dedicated to advocating
+ for the Project.
+ This includes promoting work being done by others with
+ FreeBSD; producing
+ advocacy literature to teach people about FreeBSD and help
+ make the path to
+ starting using FreeBSD or contributing to the Project
+ easier; and attending
+ and getting other FreeBSD contributors to volunteer to run
+ FreeBSD events,
+ staff FreeBSD tables, and give FreeBSD presentations.</p>
+
+ <p>The FreeBSD Foundation sponsors many conferences, events,
+ and summits
+ around the globe. These events can be BSD-related, open
+ source,
+ or technology events geared towards underrepresented
+ groups. We support
+ the FreeBSD-focused events to help provide a venue for
+ sharing knowledge,
+ to work together on projects, and to facilitate
+ collaboration between
+ developers and commercial users. This all helps provide a
+ healthy ecosystem.
+ We support the non-FreeBSD events to promote and raise
+ awareness of FreeBSD,
+ to increase the use of FreeBSD in different applications,
+ and to recruit
+ more contributors to the Project.</p>
+
+ <p>Check out some of the advocacy and education work we did
+ last quarter:</p>
+
+ <ul>
+ <li>Attended FOSDEM 2019 where we: staffed the FreeBSD Stand,
+ sponsored the
+ co-located FreeBSD Developer Summit, and gave the 25 Years
+ of FreeBSD
+ presentation in the BSD Dev room.</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Sponsored and presented at SANOG33 in Thimphu, Bhutan</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Represented FreeBSD at APRICOT 2019 in Yuseong-gu, Daejeon
+ South Korea</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Sponsored the USENIX FAST conference in Boston, MA as an
+ Industry Partner</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Ran our first ever FreeBSD track at
+ <a href="https://www.socallinuxexpo.org/scale/17x">SCALE
+ 17x</a>, which included an
+ all-day
+ <a
+ href="https://www.socallinuxexpo.org/scale/17x/presentations/getting-started-freebsd">Getting
+ Started with FreeBSD</a>
+ workshop. We were thrilled with the turnout of almost 30
+ participants and
+ received a lot of positive feedback. Thanks to Roller
+ Angel who taught the
+ class with the help of Deb Goodkin and Gordon Tetlow. We
+ also promoted
+ FreeBSD at the FreeBSD table in the Expo Hall.</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Sponsored, presented, and exhibited at FOSSASIA in
+ Singapore</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Sponsored AsiaBSDCon 2019</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Committed to sponsoring Rootconf, BSDCan, and EuroBSDcon</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Created registration systems for the Aberdeen Hackathon
+ and the upcoming
+ 2019 Vienna FreeBSD Security Hackathon</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Provided FreeBSD advocacy material</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Provided 3 travel grants to FreeBSD contributors to attend
+ many
+ of the above events.</li>
+ </ul>
+
+ <p>
+ We continued producing FreeBSD advocacy material to help
+ people promote
+ FreeBSD around the world.</p>
+
+ <p>Read more about our conference adventures in the
+ conference recaps and trip
+ reports in our
+ <a
+ href="https://www.freebsdfoundation.org/news-and-events/newsletter/">monthly
+ newsletters</a>.</p>
+
+ <p>We help educate the world about FreeBSD by publishing the
+ professionally produced FreeBSD Journal. We're excited to
+ announce that with
+ the release of the January/February 2019 issue, the
+ FreeBSD Journal is now a
+ free publication. Find out more and access the latest
+ issues at
+ <a
+ href="https://www.FreeBSDfoundation.org/journal/">www.FreeBSDfoundation.org/journal/</a>.</p>
+
+ <p>You can find out more about events we attended and
+ upcoming events at
+ <a
+ href="https://www.FreeBSDfoundation.org/news-and-events/">www.FreeBSDfoundation.org/news-and-events/</a>.</p>
+
+ <p>We also engaged with a new website developer to help us
+ improve our website
+ to make it easier for community members to find
+ information more easily and
+ to make the site more efficient.</p>
+
+ <p>Legal/FreeBSD IP</p>
+
+ <p>The Foundation owns the FreeBSD trademarks, and it is our
+ responsibility to
+ protect them. We also provide legal support for the core
+ team to investigate
+ questions that arise.</p>
+
+ <p>Go to <a
+ href="http://www.FreeBSDfoundation.org">www.FreeBSDfoundation.org</a>
+ to find out
+ how we support FreeBSD and how we can help you!</p>
+
+ </body>
+
+ </project>
+
+ <project cat='team'>
+ <title>Continuous Integration</title>
+
+ <contact>
+ <person>
+ <name>Jenkins Admin</name>
+ <email>jenkins-admin@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Li-Wen Hsu</name>
+ <email>lwhsu@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url>
+ <url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url>
+ <url href="https://wiki.freebsd.org/Jenkins">FreeBSD Jenkins wiki</url>
+ <url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url>
+ <url href="https://github.com/freebsd/freebsd-ci">freebsd-ci Repository</url>
+ <url href="https://preview.tinyurl.com/y9maauwg">Tickets related to freebsd-testing@</url>
+ <url href="https://wiki.freebsd.org/HostedCI">Hosted CI wiki</url>
+ <url href="https://hackfoldr.org/freebsd-ci-report/">FreeBSD CI weekly report</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD CI team maintains continuous integration
+ system and
+ related tasks for the FreeBSD project. The CI system
+ regularly
+ checks the changes committed to the project's Subversion
+ repository
+ can be successfully built, and performs various tests and
+ analysis
+ of the results. The results from build jobs are archived
+ in an
+ artifact server, for the further testing and debugging
+ needs. The
+ CI team members examine the failing builds and unstable
+ tests, and
+ work with the experts in that area to fix the code or
+ adjust test
+ infrastructure.</p>
+
+ <p>Starting from this quarter, we started to publish CI
+ weekly report at
+ <a
+ href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">freebsd-testing@</a>
+ mailing list. The archive is available at
+ https://hackfoldr.org/freebsd-ci-report/</p>
+
+ <p>We also worked on extending test executing environment
+ to improve the code coverage, temporarily disabling flakey
+ test cases,
+ and opening tickets to work with domain experts. The
+ details are
+ of these efforts are available in the weekly CI reports.</p>
+
+ <p>We published the
+ <a
+ href="https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md">draft
+ FCP for CI policy</a>
+ and are ready to accept comments.</p>
+
+ <p>Please see freebsd-testing@ related tickets for more
+ information.</p>
+
+ <p>Work in progress:</p>
+
+ <ul>
+ <li>Fixing the failing test cases and builds</li>
+
+ <li>Adding drm ports building test against -CURRENT</li>
+
+ <li>Implementing automatic tests on bare metal hardware</li>
+
+ <li>Implementing the embedded testbed</li>
+
+ <li>Planning for running ztest and network stack tests</li>
+
+ <li>Help more 3rd software get CI on FreeBSD through a hosted
+ CI solution</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Security-Related changes</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>ASLR</p>
+
+ <p>The ASLR (Address Space Layout Randomization) patch from
+ <a href="https://reviews.freebsd.org/D5603">review
+ D5603</a> was
+ committed into svn. While debate continues about the
+ current and
+ forward-looking value ASLR provides, having an
+ implementation in
+ the FreeBSD source tree makes it easily available to those
+ who wish
+ to use it. This also moves the conversation past the
+ relative
+ merits to more comprehensive security controls.</p>
+
+ <p>KPTI per-process control</p>
+
+ <p>The KPTI (Kernel Page Table Isolation) implementation was
+ structured
+ so that most selections of page isolation mode were local
+ to the
+ current address space. In other words, the global control
+ variable
+ pti was almost unused in the code paths, instead the
+ user/kernel
+ %cr3 values were directly loaded into registers or
+ compared to see
+ if the user page table was trimmed. Some missed bits of
+ code were
+ provided by Isilon, and then bugs were fixed and last
+ places of
+ direct use of pti were removed.</p>
+
+ <p>Now when the system starts in the pti-enabled mode,
+ proccontrol(1) can
+ be used by root to selectively disable KPTI mode for
+ children of a
+ process. The motivation is that if you trust the program
+ that you
+ run, you can get the speed of non-pti syscalls back, but
+ still run
+ your normal user session in PTI mode. E.g., firefox would
+ be properly
+ isolated.</p>
+
+ <p>Feature-control bits</p>
+
+ <p>Every FreeBSD executable now contains a bit mask intended
+ for
+ enabling/disabling security-related features which makes
+ sense for the
+ binary. This mask is part of the executable segments
+ loaded on image
+ activation, and thus is part of any reasonable way to
+ authenticate the
+ binary content.</p>
+
+ <p>For instance, the ASLR compatibility is de-facto the
+ property of the
+ image and not of the process executing the image. The
+ first (zero)
+ bit in the mask controls ASLR opt-out. Other OSes (e.g.
+ Solaris) used
+ an OS-specific dynamic flag, which has the same runtime
+ properties
+ but leaves less bits to consume in the feature-control
+ mask.</p>
+
+ <p>The feature-control mask is read both by kernel and by
+ rtld during
+ image activation. It is expected that more features will
+ be added
+ to FreeBSD and the mask can be used for enabling/disabling
+ those
+ features..</p>
+
+ <p>It is expected that a tool to manipulate the mask will be
+ provided
+ shortly, see <a
+ href="https://reviews.freebsd.org/D19290">review
+ D19290</a>.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>AXP803 PMIC driver update</title>
+
+ <contact>
+ <person>
+ <name>Ganbold Tsagaankhuu</name>
+ <email>ganbold@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The AXP803 is a highly integrated PMIC that targets
+ Li-battery
+ (Li-ion or Li-polymer) applications. It provides flexible
+ power
+ management solution for processors such as the Allwinner
+ A64 SoC.
+ This SoC is used by <a
+ href="https://www.pine64.org/pinebook/">Pinebook</a>.</p>
+
+ <p>The following updates were performed on the AXP803 driver:</p>
+
+ <ul>
+ <li>Enabled necessary bits when activating interrupts. This
+ allows
+ reading some events from the interrupt status registers.
+ These
+ events are reported to devd via system "PMU" and subsystem
+ "Battery", "AC" and "USB" such as plugged/unplugged,
+ battery
+ absent, charged and charging.</li>
+
+ <li>Added sensors support for AXP803/AXP813. Sensor values
+ such as
+ battery charging, charge state, voltage, charging current,
+ discharging current, battery capacity can be obtained via
+ sysctl.</li>
+
+ <li>Added sysctl for setting battery charging current. The
+ charging
+ current can be set using steps from 0 to 13. These steps
+ correspond to 200mA to 2800mA, with a granularity of
+ 200mA/step.</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Broadcom ARM64 SoC support</title>
+
+ <contact>
+ <person>
+ <name>Michal Stanek</name>
+ <email>mst@semihalf.com</email>
+ </person>
+ <person>
+ <name>Marcin Wojtas</name>
+ <email>mw@semihalf.com</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The Semihalf team continued working on FreeBSD support for
+ the
+ <a
+ href="https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm58712/">Broadcom
+ BCM5871X SoC series</a></p>
+
+ <p>BCM5871X are quad-core 64-bit ARMv8 Cortex-A57
+ communication
+ processors targeted for networking applications such as
+ 10G routers,
+ gateways, control plane processing and NAS.</p>
+
+ <p>Completed since the last update:</p>
+
+ <ul>
+ <li>iProc PCIe root complex (internal and external buses)</li>
+
+ <li>OTP (One Time Programmable memory) driver</li>
+ </ul>
+
+ <p>
+ In progress:</p>
+
+ <ul>
+ <li>BNXT Ethernet support</li>
+
+ <li>Crypto engine acceleration for IPsec offloading.</li>
+ </ul>
+
+ <p>
+ Todo:</p>
+
+ <ul>
+ <li>Upstreaming of work. This work is expected to be
+ submitted/merged to HEAD in the second half of
+ 2019.</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ Juniper Networks, Inc
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Capsicum</title>
+
+ <contact>
+ <person>
+ <name>Enji Cooper</name>
+ <email>ngie@freebsd.org</email>
+ </person>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Mariusz Zaborski</name>
+ <email>oshogbo@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Bora Özarslan</name>
+ <email>borako.ozarslan@gmail.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.FreeBSD.org/Capsicum">Capsicum Wiki Page</url>
+ </links>
+
+ <body>
+ <p>Three themes for Capsicum work were:</p>
+
+ <ul>
+ <li>Importing Google's Capsicum test suite into FreeBSD</li>
+
+ <li>Porting and sandboxing openrsync for FreeBSD</li>
+
+ <li>Applying capsicum to additional base system utilities</li>
+ </ul>
+
+ <p>
+ The Googletest-based Capsicum test cases are now
+ integrated into
+ FreeBSD. After some discussion with David Drysdale - the
+ main
+ maintainer and developer for the Capsicum port on Linux -
+ we decided that
+ from now the FreeBSD will be upstream for Capsicum test
+ cases.</p>
+
+ <p>The next major step was sandboxing openrsync. In the
+ course of that work we
+ extended our fileargs service with two new
+ functionalities. We modified
+ the fileargs service to allow limiting the operations
+ which can be performed,
+ and can now delegate <tt>lstat</tt> to the Casper service.</p>
+
+ <p>Furthermore, openrsync highly depends on the <tt>fts</tt>
+ API. We spend
+ some time in optimizing <tt>fts</tt> and making it sandbox
+ friendly by
+ introducing <tt>fts_openat</tt> function and removing the
+ need to change the
+ working directory to traverse the paths. The changes to
+ the <tt>fts</tt> API
+ are now in the tests phase.</p>
+
+ <p>Moreover, we improved bootstrapping for non-FreeBSD
+ machines. Thanks
+ to this work we can now build tools needed to bootstrap
+ FreeBSD which
+ use Casper services. In the base system <tt>strings</tt>
+ is now sandboxed as a
+ result.</p>
+
+ <p>We also sandboxed <tt>rtsol</tt>, <tt>rtsold</tt>, and
+ <tt>savecore</tt>.</p>
+
+ <p>We host biweekly Capsicum calls. The notes from the
+ meetings are published
+ in FreeBSD's
+ <a
+ href="https://github.com/freebsd/meetings/tree/master/capsicum">Capsium
+ meeting repository</a>
+ on GitHub.
+ If you would like to join the call do not hesitate to send
+ us an email.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>C Runtime changes</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>Several changes where made to the C runtime which
+ generally improves
+ the environment provided to an application.</p>
+
+ <p>Fix for libraries with initial exec TLS mode</p>
+
+ <p>Some libraries, most prominent of which is NVidia-provided
+ and thus
+ binary-only libGL.so.1, use so called initial exec mode
+ for TLS
+ variables access. This is the fastest mode of TLS access,
+ but its
+ drawback is that it only reliably work when the main
+ binary is linked
+ against the library, i.e. dlopen-ing the library to load
+ it at runtime
+ is not guaranteed to work.</p>
+
+ <p>This mode works by placing the TLS variables for objects
+ in one area
+ allocated during the executable initialization, which
+ somewhat
+ explains the name of the mode. An obvious consequence is
+ that if such
+ library is loaded later, there is no space in the TLS area
+ for an
+ application to put its TLS variables.</p>
+
+ <p>The FreeBSD dynamic linker is aware of misbehaviour of the
+ app
+ builders, and provides some amount of slack in the TLS
+ area to give space
+ for such libraries. But it appeared that the initial
+ content of the
+ TLS segment from libraries was not distributed among the
+ threads' TLS
+ areas, still breaking libraries which use initial exec
+ mode for TLS.</p>
+
+ <p>Another issue that somewhat mitigates mis-use of the mode
+ is the
+ <tt>DF_STATIC_TLS</tt> flag in the dynamic section. This
+ flag allows the
+ linker to check for the space earlier and avoid loading
+ dependencies
+ if there is no total required space. This linker flag was
+ implemented
+ by the BFD ld linker, but not by the LLVM lld linker.</p>
+
+ <p>The FreeBSD dynamic linker was fixed to properly
+ distribute TLS
+ initialization data to all threads' initial segments,
+ which required
+ reasonably extensive per-architecture changes to libc and
+ libthr.
+ Simultaneously, LLD was improved to mark libraries using
+ initial exec
+ TLS mode with the appropriate flag.</p>
+
+ <p>These measures should make FreeBSD more resilent to
+ improperly
+ linked libraries. The most interesting fix is to users of
+ the
+ nvidia libgl library, because it cannot be fixed by
+ relinking.</p>
+
+ <p>Use rtld malloc in libthr</p>
+
+ <p>The FreeBSD implementation of mutexes in libthr allocates
+ some
+ memory to keep the mutex data needed for mutex
+ initialization. In
+ contrast, the malloc implementation used by FreeBSD,
+ jemalloc(3),
+ requires working pthread mutexes for operation.</p>
+
+ <p>This creates chicken-and-egg problem during executable
+ startup, and
+ requires jemalloc to provide fragile hacks to make it
+ possible to
+ initialize mutexes. This has been a constant source of
+ mismatches on
+ imports of new versions of jemalloc.</p>
+
+ <p>The FreeBSD rtld implementation already contained a very
+ light-weight
+ malloc implementation, suitable for limited use in
+ pre-C-runtime
+ environments. This seemed to be the ideal fit for an
+ allocator for the
+ pthread private mutexes memory. By using this allocator, a
+ method
+ to address the cyclic dependencies between jemalloc and
+ libthr could
+ finally be implemented.</p>
+
+ <p>The entry points in the rtld malloc.c were renamed to
+ avoid a clash with
+ the libc exported symbols, and now the file is linked
+ statically into
+ libthr, providing an allocator for private mutexes and
+ pthread key
+ storage. The later was already switched to direct use of
+ mmap(2) for
+ similar reasons. Now less memory is wasted when key
+ storage requires
+ less than a page.</p>
+
+ <p>Destructors order bug</p>
+
+ <p>Alexander Kabaev (kan@) noted that C++ destructors for the
+ static objects from the linked shared libraries are
+ executed before
+ C++ destructors of the static objects from the main
+ binary. This was
+ verified both for clang++ and g++, but amusingly not for
+ <tt>__attribute__(((destructor)))</tt>.</p>
+
+ <p>The bug was introduced when init functions and init arrays
+ for main
+ binary startup are called from the rtld instead of csu (C
+ startup
+ code linked to the binary, typically from crt1.o). The
+ cause is
+ due to the somewhat complicated way of how destructors are
+ called
+ both by fini/fini arrays and rtld-registered atexit(3)
+ handler.</p>
+
+ <p>Solution is to register rtld atexit(3) handler before main
+ binary init
+ functions are called, using new internal ABI
+ <tt>__libc_atexit()</tt> function.</p>
+
+ <p>It is amusing that the bug was not noticed for so many
+ years.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>ENA FreeBSD Driver Update</title>
+
+ <contact>
+ <person>
+ <name>Michal Krawczyk</name>
+ <email>mk@semihalf.com</email>
+ </person>
+ <person>
+ <name>Marcin Wojtas</name>
+ <email>mw@semihalf.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README">ENA README</url>
+ </links>
+
+ <body>
+ <p>ENA (Elastic Network Adapter) is the smart NIC available
+ in the
+ virtualized environment of Amazon Web Services (AWS). The
+ ENA
+ driver supports multiple transmit and receive queues and
+ can handle
+ up to 100 Gb/s of network traffic, depending on the
+ instance type
+ on which it is used.</p>
+
+ <p>ENAv2 has been under development for FreeBSD, similar to
+ Linux
+ and DPDK. Since the last update internal review and
+ improvements
+ of the patches were done, followed by validation on
+ various AWS
+ instances.</p>
+
+ <p>To do:</p>
+
+ <ul>
+ <li>Upstream of the ENAv2 patches</li>
+ </ul>
+
+ <p>
+ Recently, AWS released the A1 instances which are arm64
+ instances.
+ The FreeBSD kernel was fixed, so the ENA can be used on
+ those
+ instances with no issues. There were changes required in
+ resource
+ activation in the ENA driver
+ <a
+ href="https://svnweb.freebsd.org/base?view=revision&amp;amp;revision=345371">r345371</a>
+ and the addition of a missing bus release method to the
+ nexus module
+ for aarch64
+ <a
+ href="https://svnweb.freebsd.org/base?view=revision&amp;amp;revision=345373">r345373</a>.
+ With these changes, the ENA driver can run on A1 instances
+ without
+ any known issues.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ Amazon.com Inc
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>FUSE</title>
+
+ <contact>
+ <person>
+ <name>Alan Somers</name>
+ <email>asomers@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>FUSE (File system in USErspace) allows a userspace program
+ to
+ implement a file system. It is widely used to support
+ out-of-tree file
+ systems like NTFS, as well as for exotic pseudo file
+ systems like
+ sshfs. FreeBSD's fuse driver was added as a GSoC project
+ in 2012.
+ Since that time, it has been largely neglected. The FUSE
+ software is
+ <a
+ href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&amp;amp;known_name=fusefs&amp;amp;list_id=289348&amp;amp;query_based_on=fusefs&amp;amp;query_format=advanced&amp;amp;short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&amp;amp;short_desc_type=anywordssubstr">buggy</a>
+ and out-of-date. Our implementation is about 11 years
+ behind.</p>
+
+ <p>The FreeBSD Foundation has agreed to fund a project to
+ improve the state of the
+ FreeBSD FUSE driver. So far I've written a test suite for
+ the fusefs(5)
+ module, fixed 1 previously reported bug, discovered and
+ fixed 6 new bugs, fixed
+ all of fusefs's Coverity CIDs, made some minor performance
+ enhancements and
+ done some general cleanup. During the next quarter I plan
+ to continue fixing
+ bugs, and I'll also raise the driver's API level as high
+ as I can before the
+ quarter runs out. We're currently at 7.8; the highest
+ defined level is 7.28.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Kernel ZLIB Update</title>
+
+ <contact>
+ <person>
+ <name>Yoshihiro Ota</name>
+ <email>ota@j.email.ne.jp</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://reviews.freebsd.org/D19706">Review D19706</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD system still uses an ancient (over 20
+ year-old) version
+ of zlib (version 1.0.4). The FreeBSD kernel zlib
+ implementation
+ has special enhancements only used by netgraph. There is a
+ separate
+ version of code derived from unzip 5.12 used to inflate
+ gzip files
+ in the kernel which could be replaced with a more modern
+ zlib.
+ More detailed information is written in
+ sys/modules/zlib/README in
+ the review.</p>
+
+ <p>In order to use the latest zlib, version 1.2.11, work has
+ been done
+ to revisit all existing zlib uses in the system. Most of
+ code works
+ as with the newer version of zlib as is. The unzip code
+ will need
+ some conversion work to use the newer zlib. A few callers
+ will be
+ made simplier by using some newer APIs available in the
+ updated zlib.
+ There are some zombie programs that have been broken and I
+ would
+ like to delete.</p>
+
+ <p>This will clean up zombie programs and duplicated zlib
+ code.
+ This will also make future zlib version updates easier.</p>
+
+ <p>These changes touch some very sensitive areas of the
+ system, such
+ as kernel loading, or are architecture specific like
+ armv6/armv7,
+ and also touch some legacy code like kgzip+kgzldr on i386.
+ Testers
+ and active users of these legacy zlib code are welcomed.</p>
+
+ <ul>
+ <li>armv elf_trampoline
+ Arm up to v5 can boot from gzipped kernel. This code is
+ modified
+ to use newer API for simplicity. Please verify gzipped
+ kernel
+ still boots with new code (Current code has fall back to
+ legacy
+ zlib in case of failure).
+ Please also elaborate how to link such kernel, too. I'm
+ still
+ trying to figure that out.</li>
+
+ <li>netgraph compression/decompression
+ Please help testing and/or teach how to test. Netgraph
+ compiles
+ in the FreeBSD zlib version inside.</li>
+
+ <li>gzipped a.out
+ Does anyone use gzipped a.out executables, still? If so,
+ does
+ someone have an easy and safe program to run?
+ Is a.out format i386 only?</li>
+
+ <li>zfs boot
+ Can we boot from gzipped file system today?</li>
+
+ <li>CTF
+ Checking how I can test.</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>FreeBSD boot security improvements</title>
+
+ <contact>
+ <person>
+ <name>Michal Stanek</name>
+ <email>mst@semihalf.com</email>
+ </person>
+ <person>
+ <name>Marcin Wojtas</name>
+ <email>mw@semihalf.com</email>
+ </person>
+ <person>
+ <name>Kornel Duleba</name>
+ <email>mindal@semihalf.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://svnweb.freebsd.org/changeset/base/345830">Veriexec manifest verification in kernel</url>
+ <url href="https://svnweb.freebsd.org/changeset/base/345438">TPM as entropy source</url>
+ <url href="https://svnweb.freebsd.org/changeset/base/344840">UEFI support in libsecureboot</url>
+ </links>
+
+ <body>
+ <p>FreeBSD gained TPM 2.0 (Trusted Platform Module) support
+ at the end
+ of 2018. A kernel configuration option, TPM_HARVEST, was
+ also added
+ to use the TPM RNG as system entropy source. When used
+ this way,
+ the TPM can be harvested every ten seconds for entropy
+ which is
+ mixed into the OS entropy pool. The kernel option is
+ currently
+ disabled by default in amd64 GENERIC kernel configuration.</p>
+
+ <p>UEFI Secure Boot support, developed by Semihalf, has been
+ merged
+ with sjg's Veriexec support, resulting in a unified
+ library named
+ libsecureboot. This library is used for verification of
+ kernel and
+ modules by the loader. The library uses BearSSL as the
+ cryptographic
+ backend. The library supports loading trusted and
+ blacklisted
+ certificates from UEFI (DB/DBx databases) and can use them
+ as trust
+ anchors for the verification.</p>
+
+ <p>The library is also used by Veriexec to verify and parse
+ the
+ authentication database (called 'manifest')
+ in the kernel. Previously the manifest was
+ verified and parsed by a userspace application, then sent
+ to the
+ kernel via /dev/veriexec, which was a significant
+ limitation and a
+ security weakness.</p>
+
+ <p>To do:</p>
+
+ <ul>
+ <li>Backport to stable branches.</li>
+ </ul>
+
+ <p>
+ Special thanks to sjg and Juniper for fruitful cooperation
+ around
+ Veriexec and the libsecureboot development.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ Stormshield
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>LLVM's lld as the FreeBSD system linker</title>
+
+ <contact>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/LLD">LLD on the FreeBSD Wiki</url>
+ <url href="https://bugs.freebsd.org/214864">lld exp-run</url>
+ </links>
+
+ <body>
+ <p>In FreeBSD-HEAD and 12.0 the default FreeBSD system linker
+ (i.e., <tt>/usr/bin/ld</tt>) is LLVM's lld, on amd64,
+ arm64, and armv7.
+ For i386 in 12.0 lld is used as the bootstrap linker
+ (i.e., to build the kernel and base system) but it is not
+ enabled
+ as the system linker because of multiple issues building
+ FreeBSD ports
+ with it enabled.</p>
+
+ <p>The primary issue affecting i386 with lld is that many
+ ports build
+ position-dependent code (i.e., non-PIC) for use in shared
+ libraries.
+ This either comes from omitting the <tt>-fPIC</tt>
+ compiler flag, or using
+ hand-written position-dependent assembly. Compared with
+ other
+ CPU architectures i386 position-independent code is rather
+ inefficient,
+ which may be responsible for port authors making an
+ explicit decision
+ to avoid PIC.</p>
+
+ <p>By default lld does not allow position-dependent code in
+ shared objects
+ (in particular, it does not permit relocations against
+ read-only segments -
+ typically containing the`.text` section).</p>
+
+ <p>Over the last quarter many commits were made to the ports
+ tree to fix
+ the build when the system linker is lld - either building
+ PIC code,
+ or adding the <tt>-znotext</tt> linker flag to permit
+ relocations against
+ read-only segments, or just switching the port to link
+ with GNU ld
+ if it is incompatible with lld in some other way.</p>
+
+ <p>At this point there are only a few dozen open bug reports
+ for issues
+ linking ports with lld as the system linker, and I expect
+ FreeBSD 12.1
+ to use lld as the system linker on i386 as well.</p>
+
+ <p>Tasks:</p>
+
+ <ul>
+ <li>Fix freepascal/Lazarus ports with lld</li>
+
+ <li>Triage and address remaining port failures</li>
+
+ <li>Holistic review of lld workarounds in the ports tree, to
+ identify changes
+ that are no longer needed, should be addressed in lld, or
+ should be sent
+ upstream</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>mlx5 Drivers Update</title>
+
+ <contact>
+ <person>
+ <name>Slava Shwartsman Hans Petter Selasky Konstantin Belousov</name>
+ <email>freebsd-drivers@mellanox.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="http://www.mellanox.com/page/products_dyn?product_family=193&amp;mtag=freebsd_driver">Mellanox OFED for FreeBSD Documentation</url>
+ </links>
+
+ <body>
+ <p>The mlx5 driver provides support for PCI Express adapters
+ based on
+ ConnectX-4(LX), ConnectX-5(EX) and ConnectX-6(DX).
+ The mlx5en driver provides support for Ethernet and the
+ mlx5ib driver provides
+ support for InfiniBand and RDMA over Converged Ethernet,
+ RoCE.</p>
+
+ <p>Following updates done in mlx5 drivers:</p>
+
+ <ul>
+ <li>Added support for ConnectX-6 and ConnectX-6dx devices,
+ which support of
+ up to 200Gb/s interface speeds!</li>
+
+ <li>Added TLS hardware offload support for ConnectX-6dx
+ devices. TLS Tx
+ crypto offload is a new feature for network devices. It
+ enables the kernel
+ TLS socket to skip encryption and authentication
+ operations on the transmit
+ side of the data path, delegating those to the NIC. In
+ turn, the network
+ adapter encrypts packets that belong to an offloaded TLS
+ socket on the fly.
+ The Mellanox network adapter does not modify any packet
+ headers. It expects
+ to receive fully framed TCP packets with TLS records as
+ payload. The NIC
+ replaces plaintext with ciphertext and fills the
+ authentication tag. The
+ adapter does not hold any state beyond the context needed
+ to encrypt the
+ next expected packet, i.e. expected TCP sequence number
+ and crypto state.</li>
+
+ <li>Add support for Dynamic Receive Queue Interrupt
+ Moderation. Dynamic
+ Interrupt Moderation (DIM) refers to any action made by
+ hardware and/or
+ software on run time to control interrupt rate on the
+ system. The
+ moderation action itself should not interfere with the
+ system's operation
+ and should not require any human interaction. In
+ networking, dynamic
+ interrupt moderation is used for controlling the rate of
+ interrupts
+ generated by the hardware for multiple traffic scenarios.</li>
+
+ <li>Enhanced support for self-healing mechanism:
+ In a rare occasion when Mellanox network adapters fail,
+ due to a firmware
+ bug for example, the driver will sense the catastrophic
+ error. As
+ a result of this failure detection, the device driver can
+ trigger a firmware reset for the device so it can recover
+ - without the
+ need to reboot the entire host.</li>
+
+ <li>Added support for in-driver firmware updating using
+ mlx5tool.</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ Mellanox Technologies
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>PCI Express Resets</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>konstantinb@mellanox.com</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>Sometimes the need to reset a device attached to the
+ system presents
+ itself. Preferrably this device reset can be accomplished
+ without
+ causing the whole machine to reboot. It is easy to do with
+ USB
+ devices if the physical access is available -- you can
+ just re-plug
+ the device. For in-chassis devices, built-in, or on add-on
+ cards,
+ it is not possible to reset the device with physical
+ action, unless
+ the device is hot-plugged. Nonetheless, for typical modern
+ PCIe
+ devices, and most built-in PCI-emulation devices, the
+ reset can be
+ initiated using software actions.</p>
+
+ <p>If device is a real plugged-in PCIe device, then reset can
+ be
+ initiated by disabling and then re-training PCIe-link by
+ the upstream
+ port controls. For most PCI devices, which support the PCI
+ power
+ management specification, the proven way to accomplish the
+ reset
+ is to put the device into state D3 (off) and then return
+ to the
+ previous power state.</p>
+
+ <p>FreeBSD was missing a way to conveniently request user- or
+ driver-initiated reset of devices. While it was possible
+ to manually
+ fiddle with registers using pciconf, this is impractical
+ for users,
+ and requires a lot of boilerplate code from drivers.</p>
+
+ <p>A new BUS_RESET_CHILD() method was added to the newbus bus
+ interface,
+ and implementations added for PCIe bridges and PCI
+ devices. The
+ libdevctl(3) library call and devctl(8) command provide
+ convenient
+ userspace accessors for applications and administrators.</p>
+
+ <p>During the reset, the device driver must stop its
+ operations with
+ the device. One way to achieve this is to detach drivers
+ before
+ reset, and re-attach after the device afterwards. This is
+ mostly
+ fine for network interfaces, but other devices require
+ more
+ coordination to handle properly. For example, an NVMe disk
+ device
+ being detached it means that all mounted volumes abruptly
+ disapper
+ from VFS view. Due to this, the BUS_RESET_CHILD() method
+ allows
+ the caller to select either detach/re-attach or
+ suspend/resume
+ driver actions around the reset.</p>
+
+ <p>Mellanox uses the infrastructure to perform reset of the
+ mlx(5) card
+ after firmware reset without server reboot. It is believed
+ that
+ 'devctl reset' will be more widely useful.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ Mellanox Technologies
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>CFT - Package Base</title>
+
+ <contact>
+ <person>
+ <name>Kris Moore</name>
+ <email>kmoore@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://trueos.github.io/pkgbase-docs/">Package Base CFT - FAQ</url>
+ </links>
+
+ <body>
+ <p>The TrueOS project has been working on a Package Base
+ implementation,
+ and is pleased to issue its first [CFT to the FreeBSD
+ community]<a
+ href="https://lists.freebsd.org/pipermail/freebsd-pkgbase/2019-April/000396.html">https://lists.freebsd.org/pipermail/freebsd-pkgbase/2019-April/000396.html</a>.</p>
+
+ <p>The TrueOS packaging work has been in development for
+ close to 6
+ months, and differs from the original FreeBSD package base
+ effort,
+ in that it is an "out of tree" implementation. It allows
+ any version
+ of FreeBSD to be packaged, and only requires a [patch to
+ poudriere]<a
+ href="https://github.com/freebsd/poudriere/pull/664">https://github.com/freebsd/poudriere/pull/664</a>,
+ as well
+ as some minor ports enhancements, the first which is
+ [currently in
+ review]<a
+ href="https://reviews.freebsd.org/D20055">https://reviews.freebsd.org/D20055</a>.
+ For more information
+ on the current status, please refer to the FAQ page.</p>
+
+ <p>Additionally there will be a [working-group at BSDCan
+ 2019]<a
+ href="https://wiki.freebsd.org/DevSummit/201905/PackageBase">https://wiki.freebsd.org/DevSummit/201905/PackageBase</a>,
+ and
+ we encourage porters to attend and join the discussion.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ [iXsystems Inc](https://www.ixsystems.com)
+ </sponsor>
+
+ </project>
+
+ <project cat='arch'>
+ <title>FreeBSD/RISC-V Update</title>
+
+ <contact>
+ <person>
+ <name>Ruslan Bukin</name>
+ <email>br@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Mitchell Horne</name>
+ <email>mhorne@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>Work has continued on RISC-V port in the past quarter.</p>
+
+ <p>Support for transparent superpage promotion was added to
+ the RISC-V
+ port, meaning that applications will now automatically use
+ large
+ page mappings when possible. Per-CPU pmap activation
+ tracking was
+ added, reducing the overhead of various pmap operations.
+ This
+ noticeably improves the responsiveness of FreeBSD when
+ running in
+ a multi-CPU virtual machine.</p>
+
+ <p>A RISC-V implementation of minidumps was completed.
+ Support for
+ debugging RISC-V kernel dumps will land in devel/gdb after
+ the
+ next GDB release.</p>
+
+ <p>It is now possible to compile the in-tree LLVM's RISC-V
+ target by
+ setting WITH_LLVM_TARGET_RISCV=YES in /etc/src.conf. The
+ use of
+ LLVM to compile the RISC-V port is currently experimental
+ and
+ further investigation is ongoing.</p>
+
+ <p>Work is ongoing to bring up FreeBSD on SiFive's HiFive
+ Unleashed
+ development board now that one has been obtained by a
+ FreeBSD
+ developer. We also expect to work on support for a new
+ version
+ of the SBI specification.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation, DARPA, AFRL
+ </sponsor>
+
+ </project>
+
+ <project cat='ports'>
+ <title>FreeBSD GNOME status report</title>
+
+ <contact>
+ <person>
+ <name>Koop Mast</name>
+ <email>kwm@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Eric Turgeon</name>
+ <email>ericbsd@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://freebsd.org/gnome/">GNOME FreeBSD</url>
+ <url href="https://github.com/freebsd/freebsd-ports-gnome">GNOME development Repo</url>
+ </links>
+
+ <body>
+ <p>Ports activity in this quarter where:</p>
+
+ <ul>
+ <li>The x11-toolkits/gtk30 port updated to 3.24.5 and later to
+ 3.24.7.</li>
+
+ <li>The www/webkit2-gtk3 port was updated to 2.24.0.</li>
+
+ <li>And the old insecure webkit-gtk2 and webkit-gtk3 where
+ finally removed.</li>
+ </ul>
+
+ <p>
+ Work in progress, the branches are available in the GNOME
+ development
+ repo, see the link above.</p>
+
+ <ul>
+ <li>Eric Turgeon is working on MATE 1.22 in the [mate-1.22]
+ branch.
+ And is almost complete.</li>
+
+ <li>Charlie Li (IRC: vishwin) is working on a long overdue
+ update of
+ the cinnamon desktop. This update is almost complete. The
+ only
+ real blocker is that the screensaver can't be unlocked
+ after it
+ activates. The work is in the [cinnamon] branch.</li>
+ </ul>
+
+ <p></p>
+
+ <ul>
+ <li>Koop Mast works on GNOME 3.32. The desktop is usable apart
+ from
+ gdm which is currently non-functional. Due to lack of free
+ time
+ the work is going slowly. This work is available in the
+ [gnome-3.32]
+ branch.</li>
+ </ul>
+
+ <p>
+ People who are willing to contribute can find us on
+ #freebsd-gnome
+ on freenode.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='ports'>
+ <title>FreeBSD KDE status report</title>
+
+ <contact>
+ <person>
+ <name>Adriaan de Groot</name>
+ <email>adridg@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Tobias C. Berner</name>
+ <email>tcberner@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://freebsd.kde.org/">KDE FreeBSD</url>
+ </links>
+
+ <body>
+ <p>The two biggest accomplishements this quarter were:</p>
+
+ <ul>
+ <li>Qt4 and all its consumers have been removed from the ports
+ tree.</li>
+
+ <li>www/qt5-webengine has been updated from the ancient 5.9.4
+ to 5.12.x by kai@</li>
+ </ul>
+
+ <p>
+ Further we have kept the KDE Frameworks, Plasma and
+ Applications
+ ports up to date with upstreams releases, which thanks to
+ upstreams'
+ FreeBSD-CI uses less and less patches.</p>
+
+ <p>All the kde@ maintained ports (including cmake) have been
+ kept up
+ to date with their releases.</p>
+
+ <p>The plans for the next quarter are in no particular order</p>
+
+ <ul>
+ <li>Cleanup PyQt ports and pyqt.mk</li>
+
+ <li>Improve qt.mk components</li>
+
+ <li>Update sddm to 0.18.x</li>
+
+ <li>Implement user management functionality in system settings
+ (write
+ non-logind backend)</li>
+ </ul>
+
+ <p>
+ People who are willing to contribute can find us on
+ #kde-freebsd
+ on freenode, and the kde@FreeBSD.org mailing list. Further
+ we accept
+ pull-requests and contributions on
+ github.com/freebsd/freebsd-ports-kde.</p>
+
+ <p></p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>sysctlmibinfo API 1.0</title>
+
+ <contact>
+ <person>
+ <name>Alfonso Sabato Siciliano</name>
+ <email>alfonso.siciliano@email.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://gitlab.com/alfix/sysctlmibinfo">gitlab.com/alfix/sysctlmibinfo</url>
+ </links>
+
+ <body>
+ <p>Port: <a
+ href="https://www.freshports.org/devel/libsysctlmibinfo/">devel/libsysctlmibinfo</a></p>
+
+ <p>The <tt>sysctl()</tt> system call can get or set the value
+ of a 'property'
+ of the system. A 'property' has others info (description,
+ type,
+ label, etc.), they are necessary to build an utility like
+ <tt>/sbin/sysctl</tt>,
+ example:</p>
+
+ <p>```
+ % sysctl -d kern.ostype
+ kern.ostype: Operating system type
+ % sysctl -t kern.ostype
+ kern.ostype: string
+ ```</p>
+
+ <p>Primarily <tt>sysctlmibinfo</tt> wraps the undocumented
+ kernel interface
+ and provides an easy C API: <tt>sysctlmif_name()</tt>,
+ <tt>sysctlmif_description()</tt>,
+ <tt>sysctlmif_info()</tt>,
+ <tt>sysctlmif_label()</tt>,
+ <tt>sysctlmif_nextnode()</tt> and
+ <tt>sysctlmif_nextleaf()</tt>, to retrieve
+ the info of a 'property'.</p>
+
+ <p>Moreover <tt>sysctlmibinfo</tt> provides a high level API:
+ defines a
+ <tt>struct sysctlmif_object</tt> and has some function:
+ <tt>sysctlmif_filterlist()</tt>,
+ <tt>sysctlmif_grouplist()</tt> and
+ <tt>sysctlmif_tree()</tt>, to build lists and trees of
+ objects.</p>
+
+ <p>You can use this library to quickly build a custom
+ <tt>sysctl</tt> utility.
+ For example, the core of <tt>deskutils/sysctlview</tt> (a
+ graphical explorer
+ for the sysctl MIB Tree) is just a call to
+ <tt>sysctlmif_tree()</tt> and
+ a visit to the resulting tree to show its
+ <tt>sysctlmif_object</tt> nodes.</p>
+
+ <p>Note, actually a 'property' is an OID of the sysctl MIB,
+ it is
+ implemented by a <tt>struct sysctl_oid</tt> defined in
+ <tt>sys/sysctl.h</tt>.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>sysctlview 1.0</title>
+
+ <contact>
+ <person>
+ <name>Alfonso Sabato Siciliano</name>
+ <email>alfonso.siciliano@email.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://www.gitlab.com/alfix/sysctlview">gitlab.com/alfix/sysctlview</url>
+ </links>
+
+ <body>
+ <p>Port: <a
+ href="https://www.freshports.org/deskutils/sysctlview/">deskutils/sysctlview</a></p>
+
+ <p>The FreeBSD's kernel maintains a Management Information
+ Base where
+ the objects are properties to tuning the system using the
+ <tt>sysctl()</tt> syscall and the <tt>/sbin/sysctl</tt>
+ utility. The <tt>sysctlview</tt>
+ utility is a "graphical sysctl MIB explorer", it depends
+ on <tt>gtkmm</tt>
+ (to build a GUI) and <tt>sysctlmibinfo</tt> (to retrieve
+ the info from the
+ kernel).</p>
+
+ <p>The version 1.0 provides two "TreeView":</p>
+
+ <ul>
+ <li>"Main" to show 'name', 'description', 'type', 'format' and
+ 'value'</li>
+
+ <li>"Flags" to show 'name' and a column for each 'flag'
+ defined in <tt>sys/sysctl.h</tt></li>
+ </ul>
+
+ <p>
+ The rows are "clickable" to display others info (e.g.,
+ 'label').
+ Currently <tt>sysctlview</tt> can show numeric and string
+ values, the
+ support for some opaque value will be added in the future.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>Fuzzing FreeBSD with syzkaller</title>
+
+ <contact>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Andrew Turner</name>
+ <email>andrew@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Michael Tuexen</name>
+ <email>tuexen@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/google/syzkaller">syzkaller</url>
+ </links>
+
+ <body>
+ <p>Syzkaller is a coverage-guided system call fuzzer. It was
+ originally
+ developed for Linux. It programmatically creates programs
+ consisting
+ of sequences of random system calls and executes them in a
+ VM
+ (virtual machine). Using feedback from a kernel code
+ coverage
+ facility called kcov, syskaller mutates the generated test
+ programs
+ in an attempt to expand the executed coverage of code
+ paths within
+ the kernel. Sometimes exercising a seldom or infrequently
+ used
+ code path will crash the kernel. When syzkaller manages to
+ crash
+ the running kernel in the VM, it attempts to generate a
+ minimal
+ test case which reproduces the crash, simplifying
+ debugging.
+ Syzkaller is very effective at finding kernel bugs and has
+ uncovered
+ hundreds of issues in Linux. Over the past couple of
+ years,
+ syzkaller's author, Dmitry Vyukov, has added support for
+ other
+ operating systems, including FreeBSD.</p>
+
+ <p>Recently, a number of FreeBSD developers have been using
+ syzkaller
+ to find and fix bugs in the FreeBSD kernel. If interested,
+ one can
+ search the commit logs for "syzkaller" to find examples.
+ Syzkaller
+ can be run on a FreeBSD or Linux host to fuzz FreeBSD
+ running in
+ QEMU instances. It can also fuzz FreeBSD instances running
+ on GCE
+ (Google Compute Engine). Additionally, Google maintains a
+ dedicated
+ cluster of GCE hosts to continuously fuzz the latest
+ builds of
+ several different OS kernels. A [FreeBSD
+ target]<a
+ href="https://syzkaller.appspot.com/freebsd">https://syzkaller.appspot.com/freebsd</a>
+ was recently added.
+ Subscribe to the
+ <a
+ href="https://groups.google.com/forum/#!forum/syzkaller-freebsd-bugs">syzkaller-freebsd-bugs</a>
+ Google Group to receive notifications for newly discovered
+ bugs.</p>
+
+ <p>Work is ongoing to improve syzkaller's coverage of
+ FreeBSD's system
+ calls. In particular, syzkaller needs to be taught about
+ all of
+ the target kernel's entry points and argument types in
+ order to be
+ useful. Many of the standard POSIX system calls are
+ already covered,
+ but most FreeBSD-specific system calls are not. Similarly,
+ many
+ ioctl(2) definitions are missing.</p>
+
+ <p>Some in-progress work aims to add support for bhyve as a
+ VM backend
+ for syzkaller, making it easier to fuzz FreeBSD VMs hosted
+ on
+ FreeBSD. Currently that can be done using QEMU, but QEMU
+ on FreeBSD
+ lacks support for hardware acceleration. See the
+ <a
+ href="https://github.com/google/syzkaller/pull/1150">PR</a>
+ for the
+ implementation.</p>
+
+ <p>Finally, a number of bugs identified by syzkaller have yet
+ to be
+ fixed. If you are interested in helping out with any of
+ the above,
+ please mail the contacts listed above.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='third'>
+ <title>University of Waterloo Co-operative Education Students</title>
+
+ <contact>
+ <person>
+ <name>Ed Maste</name>
+ <email>emaste@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>For the January-April 2019 term the FreeBSD Foundation has
+ again brought
+ on two co-operative education (co-op) students from the
+ University of
+ Waterloo.</p>
+
+ <p>Gerald Aryeetey is a 2nd year Computer Engineering
+ student. Gerald
+ started looking at a FreeBSD tool chain issue - our static
+ library
+ archiver (`ar`) did not read or write archives in the
+ 64-bit format.
+ Gerald submitted a
+ <a
+ href="https://github.com/libarchive/libarchive/pull/1116">libarchive
+ change</a>
+ to support 64-bit archives followed by
+ <a href="https://reviews.freebsd.org/D19814">change to
+ FreeBSD's ar</a>
+ to add 64-bit support.</p>
+
+ <p>Gerald later looked at a number of <tt>freebsd-update</tt>
+ issues in FreeBSD's
+ bugzilla database, and submitted many fixes. Around a
+ dozen have been
+ committed to FreeBSD, and more are in review.</p>
+
+ <p>Gerald also worked on the
+ <a
+ href="https://github.com/freebsdfoundation/hardware-ci">FreeBSD
+ Foundation's hardware continuous integration</a>
+ effort.
+ The prototype installation is building FreeBSD on a
+ commit-by-commit basis
+ and testing on a BeagleBone Black and a Pine64 LTS.
+ The prototype will be converted to a permanent, public
+ installation in the
+ near future, after which additional test devices will be
+ added.</p>
+
+ <p>For his final project Gerald intends to write a device
+ driver for the
+ <a
+ href="https://www.microchip.com/wwwproducts/en/LAN7430">Microchip
+ LAN743x PCIe NIC</a>.</p>
+
+ <p>Bora Özarslan is a 3rd year student in Computing and
+ Financial Management.
+ Bora's initial focus was also on tool chain issues in
+ FreeBSD, starting with
+ improvements or bug fixes in FreeBSD's <tt>readelf</tt>
+ (from the
+ <a
+ href="https://sourceforge.net/p/elftoolchain/wiki/Home/">ELF
+ Tool Chain</a> project).</p>
+
+ <p>Bora developed a
+ <a href="https://reviews.freebsd.org/D19290">tool</a> to
+ modify feature control bits
+ in ELF binaries - for example, allowing binaries
+ incompatible with ASLR to
+ request to opt-out.
+ As part of his readelf work Bora also added support to
+ report the status of
+ the feature control bits.</p>
+
+ <p>Bora continued investigating security topics, looking at
+ applying
+ <a href="https://reviews.freebsd.org/D19407">Capsicum
+ sandboxing</a> to
+ Kristaps' BSD licensed rsync implementation,
+ <a
+ href="https://github.com/kristapsdz/openrsync">openrsync</a>.
+ This work required first implementing
+ <a
+ href="https://reviews.freebsd.org/D19548">fileargs_lstat</a>
+ support in <tt>cap_fileargs</tt>
+ (which as now been committed) as well as changes to the
+ <tt>fts</tt> directory hierarchy routines (which have not
+ yet been committed to
+ FreeBSD).</p>
+
+ <p>For the rest of the work term Bora will investigate and
+ test unmodified
+ Linux Docker containers on FreeBSD, to evaluate the state
+ of Linuxulator
+ support.</p>
+
+ <p></p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='third'>
+ <title>FreeBSD Wiki Apple Intel Mac mini update</title>
+
+ <contact>
+ <person>
+ <name>Trevor Roydhouse</name>
+ <email>fbsdwiki@gmx.net</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/IntelMacMini">FreeBSD Wiki</url>
+ </links>
+
+ <body>
+ <p>The FreeBSD Wiki page for the Apple Intel Mac minis has
+ been
+ comprehensively updated over the last quarter to drag it
+ from 2009
+ into 2019.</p>
+
+ <p>There are now detailed instructions for installing FreeBSD
+ as the
+ only operating system on models from 2007 through 2014 and
+ itemised
+ model specific information detailing FreeBSD support.</p>
+
+ <p>If anyone is interested, help is needed to provide more
+ specific
+ information for the macmini 1,1 and 6,1 through 8,1 models
+ and to
+ test patches for the asmc(4) driver for temperature sensor
+ feedback
+ and for setting fan speed. If you would like to help and
+ have access
+ to these Mac minis, please contact me.</p>
+
+ <p>Future tasks:</p>
+
+ <ul>
+ <li>Create and test more patches for asmc(4) to cover all
+ Intel Mac minis</li>
+
+ <li>Provide more information for 2006, 2012, 2014 and 2018 Mac
+ minis</li>
+
+ <li>Instructions for dual boot (macOS/FreeBSD) installations</li>
+ </ul>
+
+ <p></p>
+
+ </body>
+
+ </project>
+
+</report>
\ No newline at end of file

File Metadata

Mime Type
text/plain
Expires
Thu, Jul 23, 9:48 AM (19 h, 51 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
35397863
Default Alt Text
D20446.id57998.diff (71 KB)

Event Timeline