Page MenuHomeFreeBSD
Files F131462416

D21381.diff
No OneTemporary
Actions

D21381.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
@@ -83,6 +83,7 @@
XMLDOCS+= report-2018-01-2018-09
XMLDOCS+= report-2018-09-2018-12
XMLDOCS+= report-2019-01-2019-03
+XMLDOCS+= report-2019-04-2019-06
XSLT.DEFAULT= report.xsl
Index: head/en_US.ISO8859-1/htdocs/news/status/report-2019-04-2019-06.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2019-04-2019-06.xml
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2019-04-2019-06.xml
@@ -0,0 +1,2458 @@
+<?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>April-June</month>
+
+ <year>2019</year>
+ </date>
+
+ <section>
+ <title>Introduction</title>
+
+ <p>This quarter our report includes
+ some interesting topics easily accessible to anyone, even if
+ you are not a programmer: we report the link to a presentation
+ of the 2019 FreeBSD survey results at BSDCan 2019 and describe
+ an interesting experience of a 3-person hackaton, which might
+ encourage you to host one yourself, possibly with more participants.
+ We also provide some up to date information about the status
+ of our IRC channels.</p>
+
+ <p>For those who have some more technical skills, we give some
+ news about the role of git in the FreeBSD project, describe
+ the status of some tools to hunt bugs or enhance security and
+ announce a clone of sysctl.</p>
+
+ <p>Finally, those who are more experienced with programming will
+ probably be interested in the great work that has been done
+ with drivers: in particular, an aknowledgement is due to Alan
+ Somers for having started to bring up to date our FUSE
+ implementation, which was about 11 years behind. Other important
+ improvements include a more user-friendly experience with
+ trackpoints and touchpads enabled by default, much low level
+ work on graphics, many new bhyve features, updates to the
+ linux compatibility layer, various kernel improvements.</p>
+
+ <p>Have a nice read!<br/>
+
+ -- 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>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>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://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/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 second quarter of 2019, the FreeBSD Release
+ Engineering team
+ started the 11.3-RELEASE cycle, with the code slush
+ starting May 3rd.
+ Throughout the cycle, there were three BETA builds and
+ three RC builds,
+ all of which in line with the originally-published
+ schedule. The final RC
+ build started June 28th, with the final release build
+ targeted for July 5th.</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.</p>
+
+ <p>The FreeBSD Release Engineering Team also published the
+ schedule for the
+ 12.1-RELEASE, targeted to start September 6th. One
+ important thing to note
+ regarding the published schedule is it excludes a hard
+ freeze on the
+ <tt>stable/12</tt> branch, as a test run for eliminating
+ code freezes entirely during
+ a release cycle. Commits to what will be the
+ <tt>releng/12.1</tt> branch will still
+ require explicit approval from the Release Engineering
+ Team, however.</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
+ and Rubicon
+ Communications, LLC (Netgate).</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>The following was done during the last quarter by portmgr
+ to keep things in
+ the Ports Tree going:</p>
+
+ <p>During the last quarter the number of ports rose to just
+ under 37,000. At the
+ end of the quarter, there were 2146 open PRs and 7837
+ commits (excluding 499 on
+ the quarterly branch) from 172 committers. This shows a
+ slight decrease in
+ activity compared to previous quarter.</p>
+
+ <p>People come and go, last quarter we welcomed Pedro Giffuni
+ (pfg@), Piotr Kubaj
+ (pkubaj@) and Hans Petter Selasky (hselasky@). Pedro and
+ Hans Petter were
+ already active as src committers. We said goodbye to
+ gordon@, kan@, tobez@,
+ and wosch@.</p>
+
+ <p>On the infrastructure side, a new USES=cabal was
+ introduced and various default
+ versions were updated: MySQL to 5.7, Python to 3.6, Ruby
+ to 2.5, Samba to 4.8
+ and Julia gained a default version of 1.0. The web
+ browsers were also updated:
+ Firefox to 68.0 and Chromium to 75.0.3770.100</p>
+
+ <p>During the last quarter, antoine@ ran a total of 41
+ exp-runs to test various
+ package updates, bump the stack protector level to
+ "strong", switch the default
+ Python version to 3.6 as opposed to 2.7, remove sys/dir.h
+ from base which has
+ been deprecated for over 20 years, and convert all Go
+ ports to USES=go.</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>
+
+ <ul>
+ <li>Core approved source commit bits for Doug Moore (dougm),
+ Chuck Silvers
+ (chs), Brandon Bergren (bdragon), and a vendor commit bit
+ for Scott
+ Phillips (scottph).</li>
+ </ul>
+
+ <ul>
+ <li>The annual developer survey closed on 2019-04-02. Of the
+ 397
+ developers, 243 took the survey with an average completion
+ time of 12
+ minutes. The public survey closed on 2019-05-13. It was
+ taken by
+ 3637 users and had a 79% completion rate.
+ <a
+ href="https://www.youtube.com/watch?v=9nc8N6GtAPg&amp;t=549">A
+ presentation of the survey results</a>
+ took place at BSDCan 2019.</li>
+ </ul>
+
+ <ul>
+ <li>The core team voted to appoint a working group to explore
+ transitioning our source code 'source of truth' from
+ Subversion to
+ Git. Core asked Ed Maste to chair the group as Ed has been
+ researching this topic for some time. For example, Ed gave
+ <a href="https://www.youtube.com/watch?v=G8wQ88d85s4">a
+ MeetBSD 2018 talk on the topic</a>.</li>
+ </ul>
+
+ <p>
+ There is a variety of viewpoints within core regarding
+ where and how
+ to host a Git repository, however core feels that Git is
+ the prudent
+ path forward.</p>
+
+ <ul>
+ <li>The project received many Season of Docs submissions and
+ picked a top
+ candidate. Google will announce the accepted technical
+ writer
+ projects on 2019-08-06. We are hoping for lots of new and
+ refreshed
+ man pages.</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://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 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>The
+ <a
+ href="https://github.com/freebsd/fcp/blob/master/fcp-20190401-ci_policy.md">FCP
+ for CI policy</a>
+ is in "feedback" state, please provide any comments to
+ freebsd-testing@ or
+ other suitable lists.</p>
+
+ <p>We had a testing working group in <a
+ href="https://wiki.freebsd.org/DevSummit/201905/TestingCI">201905
+ DevSummit</a></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>Adding powerpc64 tests job: <a
+ href="https://github.com/freebsd/freebsd-ci/pull/33">https://github.com/freebsd/freebsd-ci/pull/33</a></li>
+
+ <li>Implementing automatic tests on bare metal hardware</li>
+
+ <li>Extending and publishing 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>
+
+ </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>In the last report, half a year ago, several updates and
+ changes had been made
+ to the FreeBSD graphics stack.</p>
+
+ <p>To further improve the user experience, and to improve
+ input device handling,
+ evdev was enabled in the default configuration in late
+ 2018. Building on that,
+ we have enabled IBM/Lenovo trackpoints and elantech and
+ synaptics touchpads by
+ default as well.</p>
+
+ <p>The input device library libinput has been updated as the
+ last in a series of
+ updates bringing the userland input stack up to date.
+ This is work that was started in 2018.</p>
+
+ <p>We have made several improvements to the drm kernel
+ drivers.
+ A long-standing memory leak in the Intel (i915) driver has
+ been fixed, and
+ several other updates and improvements have been made to
+ the various drm
+ kernel driver components.</p>
+
+ <p>A port of the drm kernel drivers using the 5.0 Linux
+ kernel sources has been
+ created and committed to FreeBSD ports as
+ <tt>graphics/drm-devel-kmod</tt>.
+ This driver requires a recent Linux KPI and is only
+ available on recent
+ versions of FreeBSD CURRENT.</p>
+
+ <p>This version of the driver contains several development
+ improvements.
+ The generic drm (drm.ko) driver as well as the i915
+ (i915kms.ko) driver
+ can now be unloaded and reloaded to ease in development
+ and testing.
+ This causes issues with the virtual consoles, however, so
+ an SSH connection is
+ recommended.
+ To aid debugging <tt>i915kms.ko</tt> use of debugfs has
+ been improved, but there are
+ still limitations preventing it from being fully
+ functional.
+ Since debugfs is based on pseudofs it is possible that
+ this will prevent a fully
+ functional debugfs in its current state, so we might have
+ to look into adding
+ the required functionality to pseudofs or use another
+ framework.</p>
+
+ <p>The new in-kernel drm driver for VirtualBox,
+ <tt>vboxvideo.ko</tt> has been ported from
+ Linux.
+ Support is currently an experimental work in progress.
+ For example the virtual console won't update after loading
+ the driver, but X-
+ and Wayland-based compositors are working.</p>
+
+ <p>Mesa has been updated to 18.3.2 and switched from using
+ <tt>devel/llvm60</tt> to use
+ the Ports default version of llvm, currently
+ <tt>devel/llvm80</tt>.</p>
+
+ <p>Several userland Xorg drivers, applications, and libraries
+ have been updated,
+ and other improvements to the various userland components
+ that make up the
+ Graphics Stack have been made.</p>
+
+ <p>We have also continued our regularly scheduled bi-weekly
+ meetings, although work
+ remains in sending out timely meeting minutes afterwards.</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='team'>
+ <title>IRC Admin</title>
+
+ <contact>
+ <person>
+ <name>IRC Admin</name>
+ <email>irc@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The FreeBSD IRC Admin team manages the FreeBSD Project's
+ presence
+ and activity on the freenode IRC network, looking after:</p>
+
+ <ul>
+ <li>Registration and management of channels within the
+ official namespace (#freebsd*)</li>
+
+ <li>Channel moderation</li>
+
+ <li>Liaising with freenode staff</li>
+
+ <li>Allocating <tt>freebsd/*</tt> hostmask cloaks for users</li>
+
+ <li>General user support relating to channel management</li>
+ </ul>
+
+ <p>
+ While the FreeBSD Project does not _currently_ endorse IRC
+ as an
+ official support channel [1][2], as it has not been able
+ to guarantee
+ a consistent or positive user experience, IRC Admin has
+ been working
+ toward creating a high quality experience, by
+ standardising channel
+ administration and moderation expectations, and ensuring
+ the projects
+ ability to manage all channels within its namespace.</p>
+
+ <p>In the last quarter, IRC Admin:</p>
+
+ <ul>
+ <li>Cleaned up (deregistered) registrations for channels that
+ were defunct,
+ stale, out of date, or had founders that were inactive
+ (not seen for &gt; 1
+ year). Channels that were found to be otherwise active
+ have been retained.
+ FreeBSD now has ~40 channels registered from a previous
+ total of over 150.</li>
+
+ <li>Documented baseline configuration settings in the Wiki for
+ channels,
+ including ChanServ settings, channel modes, registration
+ policy, etc.</li>
+
+ <li>Established multiple documented methods for reporting user
+ abuse
+ or other channel issues to IRC Admin for resolution</li>
+ </ul>
+
+ <p>
+ Upcoming changes:</p>
+
+ <ul>
+ <li>Work with existing <tt>#freebsd*</tt> channels to
+ standardise channel management,
+ settings and access.</li>
+
+ <li>Migrate, forward and/or consolidate existing or duplicate
+ <tt>#freebsd*</tt>
+ channels to channels with a standard naming convention.</li>
+
+ <li>Work with unofficial <tt>##freebsd*</tt> channels to
+ migrate them to the official
+ <tt>#freebsd*</tt> channels if suitable</li>
+
+ <li>Update existing IRC-related website and documentation
+ sources the describe
+ the official state of project managed IRC presence on
+ freenode.</li>
+ </ul>
+
+ <p>
+ Lastly, and to repeat a previous call, while the vast
+ majority of
+ the broader user community interacts on the freenode IRC
+ network,
+ the FreeBSD developer presence still needs to be
+ significantly
+ improved on freenode.</p>
+
+ <p>There are many opportunities to be had by increasing the
+ amount and
+ quality of interaction between FreeBSD users and
+ developers, both
+ in terms of developers keeping their finger on the pulse
+ of the
+ community and in encouraging and cultivating greater
+ contributions
+ to the Project over the long term.</p>
+
+ <p>It is critical to have a strong developer presence amongst
+ users,
+ and IRC Admin would like again to call on all developers
+ to join
+ the FreeBSD freenode channels to increase that presence.</p>
+
+ <p>Users are invited to <tt>/join #freebsd-irc</tt> on the
+ freenode IRC network
+ if they have questions, ideas, constructive criticism, and
+ feedback
+ on how the FreeBSD Project can improve the service and
+ experience
+ it provides to the community on IRC.</p>
+
+ <p>[1] https://www.freebsd.org/community/irc.html
+ [2]
+ https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/support.html#irc</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>bhyve - Live Migration</title>
+
+ <contact>
+ <person>
+ <name>Elena Mihailescu</name>
+ <email>elenamihailescu22@gmail.com</email>
+ </person>
+ <person>
+ <name>Darius Mihai</name>
+ <email>dariusmihaim@gmail.com</email>
+ </person>
+ <person>
+ <name>Mihai Carabas</name>
+ <email>mihai@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Virtual-Machine-Migration-using-bhyve">Github wiki - How to Live and Warm Migrate a bhyve guest</url>
+ <url href="https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migration">Github - Warm Migration branch</url>
+ <url href="https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_migration_dev">Github - Live Migration branch</url>
+ </links>
+
+ <body>
+ <p>The Migration feature uses the Save/Restore feature to
+ migrate a bhyve guest
+ from a FreeBSD host to another FreeBSD host. To migrate a
+ bhyve guest,
+ one needs to start an empty guest on the destination host
+ from a shared guest
+ image using the bhyve tool with the <tt>-R</tt> option
+ followed by the source host
+ IP and the port to listen to migration request. On the
+ source host, the
+ migration is started by executing the bhyvectl command
+ with the <tt>--migrate</tt>
+ or <tt>--migrate-live</tt> option, followed by the
+ destination host IP and the
+ port to send to the messages.</p>
+
+ <p>New features added:</p>
+
+ <ul>
+ <li>Clear the dirty bit after each migration round</li>
+
+ <li>Extend live migration to highmem segment</li>
+ </ul>
+
+ <p>
+ Future tasks:</p>
+
+ <ul>
+ <li>Refactor live migration branch</li>
+
+ <li>Rebase live migration</li>
+
+ <li>Extend live migration to unwired memory</li>
+ </ul>
+
+ </body>
+
+ <sponsor>
+ Matthew Grooms
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>bhyve - Save/Restore</title>
+
+ <contact>
+ <person>
+ <name>Elena Mihailescu</name>
+ <email>elenamihailescu22@gmail.com</email>
+ </person>
+ <person>
+ <name>Darius Mihai</name>
+ <email>dariusmihaim@gmail.com</email>
+ </person>
+ <person>
+ <name>Mihai Carabas</name>
+ <email>mihai@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/FreeBSD-UPB/freebsd/tree/projects/bhyve_snapshot">Github repository for the snapshot feature for bhyve</url>
+ <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Save-and-Restore-a-virtual-machine-using-bhyve">Github wiki - How to Save and Restore a bhyve guest</url>
+ <url href="https://github.com/FreeBSD-UPB/freebsd/wiki/Suspend-Resume-test-matrix">Github wiki - Suspend/resume test matrix</url>
+ <url href="https://reviews.freebsd.org/D19495">Phabricator review - bhyve Snapshot Save and Restore</url>
+ </links>
+
+ <body>
+ <p>The Save/Restore for bhyve feature is a suspend and resume
+ facility added to the
+ FreeBSD/amd64's hypervisor, bhyve. The bhyvectl tool is
+ used to save the guest
+ state in three files (a file for the guest memory, a file
+ for the states of
+ various devices and the state of the CPU, and another one
+ for some metadata that
+ is used in the restore process).
+ To suspend a bhyve guest, the bhyvectl tool must be run
+ with the <tt>--suspend
+ &lt;state_file_name&gt;</tt>
+ option followed by the guest name.</p>
+
+ <p>To restore a bhyve guest from a checkpoint, one simply has
+ to add the <tt>-r</tt> option
+ followed by the main state file (the same file that was
+ given to the <tt>--suspend</tt>
+ option for bhyvectl) when starting the VM.</p>
+
+ <p>New features added:</p>
+
+ <ul>
+ <li>Open ticket on Phabricator</li>
+
+ <li>Apply feedback received from community</li>
+ </ul>
+
+ <p>
+ Future tasks:</p>
+
+ <ul>
+ <li>Add suspend/resume support for nvme</li>
+
+ <li>Add suspend/resume support for virtio-console</li>
+
+ <li>Add suspend/resume support for virtio-scsi</li>
+
+ <li>Add TSC offsetting for restore for AMD CPUs</li>
+ </ul>
+
+ </body>
+
+ <sponsor>
+ Matthew Grooms
+ </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>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>Upstream of the ENAv2 patches - revisions
+ <a
+ href="https://svnweb.freebsd.org/base?view=revision&amp;revision=348383">r348383</a>
+ -
+ <a
+ href="https://svnweb.freebsd.org/base?view=revision&amp;revision=348416">r348416</a>
+ introduce a major driver upgrade to version v2.0.0. Along
+ with various fixes
+ and improvements, the most significant features are LLQ
+ (Low Latency Queues)
+ and independent queues reconfiguration using sysctl
+ commands.</li>
+
+ <li>Implement NETMAP support for ENA</li>
+ </ul>
+
+ <p>
+ Todo:</p>
+
+ <ul>
+ <li>Internal review and upstream of NETMAP support</li>
+ </ul>
+
+ </body>
+
+ <sponsor>
+ Amazon.com Inc
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>FUSE</title>
+
+ <contact>
+ <person>
+ <name>Alan Somers</name>
+ <email>asomers@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>FUSE (File system in USErspace) allows a userspace program
+ to
+ implement a file system. It is widely used to support
+ out-of-tree file
+ systems like NTFS, as well as for exotic pseudo file
+ systems like
+ sshfs. FreeBSD's fuse driver was added as a GSoC project
+ in 2012.
+ Since that time, it has been largely neglected. The FUSE
+ software is
+ <a
+ href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&amp;known_name=fusefs&amp;list_id=289348&amp;query_based_on=fusefs&amp;query_format=advanced&amp;short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&amp;short_desc_type=anywordssubstr">buggy</a>
+ and out-of-date. Our implementation is about 11 years
+ behind.</p>
+
+ <p>During Q2 I nearly finished the FUSE overhaul that I
+ begain in Q1. I raised
+ the protocol level from 7.8 to 7.23, fixed many bugs (see
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199934">199934</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216391">216391</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233783">233783</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234581">234581</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235773">235773</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235774">235774</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235775">235775</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236226">236226</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236231">236231</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236236">236236</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239291">239291</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236329">236329</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236379">236379</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236381">236381</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236405">236405</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236327">236327</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236466">236466</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236472">236472</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236473">236473</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236474">236474</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236530">236530</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236557">236557</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236560">236560</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236647">236647</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236844">236844</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237052">237052</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237181">237181</a>,
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237588">237588</a>,
+ and
+ <a
+ href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238565">238565</a>),
+ and added
+ the following features:</p>
+
+ <ul>
+ <li>Optional kernel-side permissions checks (`-o
+ default_permissions`)</li>
+
+ <li>Implement <tt>VOP_MKNOD</tt>, <tt>VOP_BMAP</tt>, and
+ <tt>VOP_ADVLOCK</tt></li>
+
+ <li>Allow interrupting FUSE operations</li>
+
+ <li>Support named pipes and unix-domain sockets in fusefs file
+ systems</li>
+
+ <li>Forward <tt>UTIME_NOW</tt> during <tt>utimensat(2)</tt> to
+ the daemon</li>
+
+ <li><tt>kqueue</tt> support for <tt>/dev/fuse</tt></li>
+
+ <li>Allow updating mounts with <tt>mount -u</tt></li>
+
+ <li>Allow exporting fusefs file systems over NFS</li>
+
+ <li>Server-initiated invalidation of the name cache or data
+ cache</li>
+
+ <li>Respect <tt>RLIMIT_FSIZE</tt></li>
+
+ <li>Try to support servers as old as protocol 7.4</li>
+ </ul>
+
+ <p>
+ I also added the following performance enhancements:</p>
+
+ <ul>
+ <li>Implement FUSE's <tt>FOPEN_KEEP_CACHE</tt> and
+ <tt>FUSE_ASYNC_READ</tt> flags</li>
+
+ <li>Cache file attributes</li>
+
+ <li>Cache lookup entries, both positive and negative</li>
+
+ <li>Server-selectable cache modes: writethrough, writeback, or
+ uncached</li>
+
+ <li>Write clustering</li>
+
+ <li>Readahead</li>
+
+ <li>Use <tt>counter(9)</tt> for statistical reporting</li>
+ </ul>
+
+ <p>
+ All that remains is to finish merging the branch, and deal
+ with any newly
+ introduced bugs.</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>Kernel zlib upgrade is in progress.</p>
+
+ <p>Xin (delphij@) and I have been working closely for zlib
+ upgrade.
+ We relocated contrib/zlib to sys/contrib/zlib in order for
+ kernel
+ code to access zlib in the tree. We also deleted dead code
+ that
+ depended on zlib and inflate - inflate is a fork of unzip
+ to
+ uncompress gzip files. We also renamed crc.h to avoid
+ conflicts
+ with zlib/crc.h.</p>
+
+ <p>Next goal is to compile both old zlib and new zlib into
+ the kernel
+ allowing to switch each zlib user independently.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Linux compatibility layer update</title>
+
+ <contact>
+ <person>
+ <name>Edward Tomasz Napierala</name>
+ <email>trasz@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The project aims to improve the Linux compatibility layer,
+ to make
+ it more compatible with recent Linux releases, and also to
+ lower
+ the bar for potential developers who want to start
+ contributing to it.</p>
+
+ <p>The initial effort focused on tooling, to make it easier
+ to debug
+ problems and to prevent future regressions. The first part
+ involved
+ making it possible to use Linux strace(1) utility and
+ providing it
+ as <tt>linux-c7-strace</tt> package. The reason is that
+ while FreeBSD
+ <tt>truss(1)</tt> and <tt>ktrace(1)</tt> can trace Linux
+ binaries, they cannot
+ decode Linux-specific flags and structures.</p>
+
+ <p>The second part involved providing Linux Test Project
+ binaries as
+ <tt>linux-ltp</tt> package. There is ongoing work to hook
+ it up to the
+ FreeBSD CI infrastructure <a
+ href="http://ci.FreeBSD.org">http://ci.FreeBSD.org</a>.</p>
+
+ <p>There was also a number of improvements and fixes to bugs
+ discovered
+ in the process. One of them (not yet committed) fixes
+ binaries
+ linked against newer version of libc, effectively
+ unbreaking binaries
+ from recent Ubuntu releases.</p>
+
+ </body>
+
+ <sponsor>
+ FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Lock-less delayed invalidation for amd64 pmap</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The Virtual Memory machine-dependent layer (pmap) on amd64
+ needs to
+ track all mappings for the managed physical memory pages,
+ to be able
+ to either destroy all of them (for page-out), or change
+ them from
+ writeable to read-only (e.g. to sync the page content to
+ file, without
+ racing with modifications through user writes). The
+ mappings are
+ accounted by creating pv_entry which records the address
+ space
+ (implicitly, by linking the pv entry to pmap) and the
+ virtual address
+ of the mapping.</p>
+
+ <p>Previous work split the lock protecting the pv entries
+ lists from
+ other VM locks into the pvh_global_lock lock, which was
+ global for all
+ address spaces. You can see it in i386 pmap.c still.
+ Later, hashed
+ per-page pv lists locks were introduced, which would
+ reduce contention
+ on pv lists maninulations for different pages, but
+ unfortunately the
+ pvh_global_lock was still needed to guarantee the safety
+ of some
+ operations.</p>
+
+ <p>Problem arises because amd64 pmap uses pmap lock to
+ protect page
+ tables and TLB consistency, which is per-pmap locks
+ different from pv
+ lists locks. When updating page table entry, we never drop
+ pmap lock
+ until the necessary TLB invalidation is done globally,
+ including
+ signalling other CPUs with IPI. But pv list locks can be
+ unlocked
+ before the necessary invalidation is done. So for instance
+ when pmap
+ is asked to remove all mappings of the specific page
+ (pmap_remove_all(9)), it checks pv list of the page to
+ find the
+ mappings. The list might appear empty despite other CPUs
+ TLB were not
+ yet invalidated. If such page is reused, other CPUs might
+ change its
+ content using cached TLB entries. Allowing that means
+ allowing both
+ silent data corruption and opening security hole.</p>
+
+ <p>So the global pvh lock was held until all pmaps
+ invalidated their
+ TLBs. This mechanism has obvious scalability issues, and
+ instead a
+ generation-count based scheme for handling delayed
+ invalidation (DI)
+ was developed, where each thread that might remove entry
+ from pv list
+ acquired a generation number and marked the page with it,
+ see
+ pmap_delayed_invl_page(9). Then, on e.g.
+ pmap_remove_all(9) or
+ pmap_remove_write(9), pmap code waits for the maximum
+ current thread's
+ invalidation generation number to pass the page's
+ generation, which
+ guarantees that all required TLB invalidations are done.</p>
+
+ <p>Original implementation of DI allowed to get rid of
+ pvh_global_lock,
+ and only used a private mutex to handle sequential
+ queueing of the
+ coming and leaving threads, protecting a bounded region. A
+ problem
+ with that appeared e.g. in scalability benchmarks which
+ did massive
+ parallel unmaps, causing most of the threads to contend on
+ DI
+ queueing.</p>
+
+ <p>Current implementation of DI switched to lock-less queue
+ algorithm
+ using the approach proposed by T.L. Harris and relying on
+ double-CAS
+ to coalesce generation count and queueing. It uses ifuncs
+ to select
+ either previous locked DI or current lock-less
+ implementation, only
+ old AMD Athlons which did not implemented the CMPXCHG16B
+ instruction
+ falls to the locked implementation by default. Lock-less
+ implementation still blocks the waiting thread on
+ turnstile to avoid
+ priority-inversion issues, but practically the wait occur
+ very rare,
+ typical parallel buildworld generates single-digit number
+ of the
+ events.</p>
+
+ <p>The patch got a lot of testing from Peter Holm, continuous
+ reviews by
+ Mark Johnston while I worked out bugs and live-lock
+ problems in the
+ implementation, and additional testing by Mateusz Guzik
+ who helped to
+ identify a priority inversion bug with the wait.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Mellanox 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 ConnectX-4 [Lx],
+ ConnectX-5 [Ex] and
+ ConnectX-6 [Dx] adapter cards. The mlx5en driver provides
+ support for Ethernet
+ adapter cards, whereas mlx5ib driver provides support for
+ InfiniBand adapters
+ and RDMA over Converged Ethernet (RoCE).</p>
+
+ <p>Following updates done in mlx5 drivers:</p>
+
+ <ul>
+ <li>200Gb/s ConnectX-6 Ethernet:
+ Added support for <a
+ href="http://www.mellanox.com/page/products_dyn?product_family=285&amp;amp;mtag=socketdc">Mellanox
+ Socket Direct Adapters</a>
+ which allows, among the rest of the capabilities, to run
+ up to 200Gb/s on a
+ PCIe Gen 3.0 on a LAG interface.</li>
+
+ <li>Support for "BlueField" - Multicore System On A Chip:
+ Added support for RShim driver for <a
+ href="http://www.mellanox.com/products/bluefield-overview/">BlueField
+ Multicore System On A Chip(SOC)</a>.
+ The RShim driver provides access to the RShim resources on
+ the BlueField
+ target accessible from an external host machine. The
+ current RShim version
+ provides device files for boot image push and virtual
+ console access. It
+ also creates virtual network interface to connect to the
+ BlueField target
+ and provides access to internal RShim registers.</li>
+
+ <li>Firmware Burning and Diagnostics Tools:
+ Added MSTFLINT to ports, this package contains a burning
+ and diagnostic
+ tools for Mellanox NICs.
+ This package contains following tools:
+ mstflint - Tools which allows to query and burn firmware.
+ mstconfig - This tool queries and sets non-volatile
+ configurable options for
+ Mellanox HCAs.
+ mstregdump - This utility dumps hardware registers from
+ Mellanox hardware.
+ mstmcra - This debug utility reads/writes a to/from the
+ device
+ configuration register space.
+ mstvpd - This utility dumps the on-card VPD.
+ and more.</li>
+
+ <li>OFED-FreeBSD-v3.5.1 Upstream:
+ Pushed upstream and MFCed OFED-FreeBSD-v3.5.1 driver -
+ more details
+ on the content of this update can be found in <a
+ href="http://www.mellanox.com/page/products_dyn?product_family=193&amp;amp;mtag=freebsd_driver">Mellanox
+ OFED for FreeBSD documentation</a> page.</li>
+ </ul>
+
+ <p>
+ General updates:</p>
+
+ <ul>
+ <li>Submitted papers for EuroBSDcon for a joint talk with
+ Netflix titled
+ "Kernel TLS and TLS Hardware Offload". The papers were
+ accepted.</li>
+
+ <li>Mellanox is intensively working to improve its cooperation
+ with the FreeBSD
+ community. As part of this effort, FreeBSD users are
+ invited to propose
+ features and enhancements to further develop and enrich
+ the end-user
+ experience. In addition, Mellanox continues to identify
+ and present the
+ right solutions to meet customers' needs.</li>
+ </ul>
+
+ </body>
+
+ <sponsor>
+ Mellanox Technologies
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>NFSv4.2 client/server implementation for FreeBSD</title>
+
+ <contact>
+ <person>
+ <name>Rick Macklem</name>
+ <email>rmacklem@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://svnweb.freebsd.org/base/projects/nfsv42">current sources</url>
+ </links>
+
+ <body>
+ <p>NFSv4.2 is a newer minor version of NFSv4, made up of a
+ set of optional
+ operations/features. A majority of these operations are
+ related to
+ the POSIX operations posix_fadvise(2), posix_fallocate(2)
+ and lseek(2)'s
+ support for SEEKHOLE/SEEKDATA. There is also a Copy
+ operation that allows
+ a byte range of a file to be copied to another file
+ locally on the NFS
+ server, avoiding data transfer over the wire in both
+ directions.
+ FreeBSD-current now has a Linux compatible
+ copy_file_range(2) syscall
+ that will invoke this Copy operation on NFSv4.2 mounts.
+ There is also support for MAC labelling, but it requires
+ changes to the
+ RPCSEC_GSS implementation to add V3 support and, as such,
+ may not happen
+ soon.</p>
+
+ <p>The implementation of NFSv4.2 (RFC-7862) is progressing
+ nicely.
+ At this time, the LayoutError, IOAdvise, Allocate and Copy
+ operations
+ have been implemented. There is still work to be done on
+ Copy, to add
+ asynchronous support, so that large copies do not result
+ in a long delay
+ for the RPC's reply.</p>
+
+ <p>The major operation that will be implemented next is Seek,
+ so that
+ lseek(SEEKHOLE/SEEKDATA) will work for the NFSv4.2 mounts.</p>
+
+ <p>It is hoped that this implementation will be ready for
+ FreeBSD-current/head
+ in time for the FreeBSD-13 release.</p>
+
+ <p>Testing is always appreciated and can be done by
+ downloading the modified
+ kernel from the svn repository in base/rojects/nfsv42 and
+ then building
+ and testing it on a couple of recent FreeBSD-current
+ systems.</p>
+
+ <p>If anyone is conversant with Kerberos and wants to take on
+ the challenge
+ of adding RPCSEC_GSS_V3 support to the kernel RPC, a patch
+ that does
+ that would also be greatly appreciated.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <title>NUMA awareness in the FreeBSD kernel</title>
+
+ <contact>
+ <person>
+ <name>Jeff Roberson</name>
+ <email>jeff@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Andrew Gallatin</name>
+ <email>gallatin@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>A set of patches to improve the state of NUMA awareness in
+ the FreeBSD
+ kernel are being developed and refined. This work also
+ aims to
+ generally improve the performance of FreeBSD's memory
+ management
+ subsystem on systems with many CPUs.</p>
+
+ <p>FreeBSD 12.0 featured a number of large changes which
+ improve its
+ performance on systems with a non-uniform memory
+ architecture. That is,
+ systems in which memory access latency for a given address
+ varies
+ depending on the CPU. Another round of improvements is
+ being developed
+ and will soon be available in FreeBSD-CURRENT. Short
+ descriptions of
+ some of these patches follow; a few have already been
+ committed to
+ FreeBSD-CURRENT.</p>
+
+ <p>In FreeBSD terminology, a memory page whose contents may
+ not be evicted
+ is referred to as "wired." Pages may be wired under
+ different
+ circumstances: for instance, all kernel memory is wired,
+ and userland
+ applications may request that ranges of memory be wired
+ using the
+ mlock(2) and mlockall(2) system calls. FreeBSD has
+ historically defined
+ a system-wide limit on the number of wired pages so as to
+ avoid
+ deadlocks that may arise when too much of a system's
+ memory cannot be
+ reclaimed to satisfy new memory allocations. This limit
+ was applied
+ only to userland wiring requests, but kernel wirings were
+ counted
+ against the limit, so a large source of kernel wirings
+ could cause
+ mlock(2) failures. This occurs frequently with a large ZFS
+ ARC, for
+ example. In FreeBSD-CURRENT this limit has been changed
+ such that only
+ userland wirings are counted against the limit; the kernel
+ contains a
+ number of mechanisms to apply back-pressure to kernel
+ memory usage, so
+ the use of a global limit on all wirings did not provide
+ much benefit.
+ This fixes a common problem on large ZFS systems, and
+ helps enable some
+ other architectural improvements to the code which manages
+ page wirings.</p>
+
+ <p>FreeBSD has historically maintained two separate reference
+ counters in
+ the structure which describes a single physical page of
+ memory. These
+ counters initially had quite different properties, but
+ have over time
+ become more and more similar. Some work to merge the two
+ counters has
+ landed in FreeBSD-CURRENT. This does not have any
+ user-visible effects,
+ but it simplifies the page management code and removes a
+ large amount of
+ code which existed solely to transform references of one
+ type to the
+ other. Such code also made use of heavily contended locks,
+ so the
+ simplification improved kernel scalability for some
+ workloads and has
+ enabled further scalability improvements.</p>
+
+ <p>UMA is the slab allocator used in FreeBSD's kernel. It is
+ the backend
+ which services virtually all dynamic memory allocations
+ performed in the
+ kernel. The first round of NUMA improvements added NUMA
+ awareness to
+ the "keg" layer of UMA, which allocates and manages slabs.
+ However, the
+ frontend of UMA, which provides several layers of caching
+ for objects,
+ did not provide domain-aware caching, so over time the
+ caches would
+ become "polluted" with objects from different memory
+ domains. However,
+ this caching layer is being modified to ensure that
+ objects from
+ different memory domains are partitioned, helping ensure
+ that consumers
+ can perform domain-local allocations and frees
+ efficiently. This will
+ enable a global "first-touch" allocation policy for
+ UMA-managed objects.</p>
+
+ <p>During boot, the FreeBSD kernel allocates a number of
+ static data
+ structures to track physical memory. These structures have
+ historically
+ lived in the lowest available range of physical memory, so
+ they many not
+ inhabit the same NUMA domain as the memory that they
+ track. This is
+ suboptimal when one tries to affinitize a workload to a
+ particular NUMA
+ domain: if while executing the workload the kernel
+ frequently accesses
+ page structures for local memory, and the page structures
+ themselves
+ are not placed in local memory, the kernel will perform
+ many remote
+ memory accesses. Some in-progress work for the amd64
+ platform creates
+ multiple arrays of page tracking structures, one per NUMA
+ domain, and
+ ensures that each array is local to its domain. This
+ complicates the
+ task of initializing kernel data structures during boot,
+ but can
+ substantially reduce the amount of cross-domain
+ communication that
+ occurs while the kernel is performing useful work.
+ Similarly, some
+ patches to affinitize per-CPU structures are being
+ developed; while
+ most per-CPU memory allocations already return CPU-local
+ memory, some
+ structures allocated during boot are not yet properly
+ placed with
+ respect to the accessing CPU's memory domain.</p>
+
+ </body>
+
+ <sponsor>
+ Netflix
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>FreeBSD SDIO and Broadcom FullMAC WiFi Support</title>
+
+ <contact>
+ <person>
+ <name>Bjoern Zeeb</name>
+ <email>bz@FreeBSD.ORG</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/SDIO">FreeBSD Wiki SDIO page</url>
+ </links>
+
+ <body>
+ <p>SDIO is an interface designed as an extension to SD Cards
+ to allow attachments of various other peripherals, e.g.,
+ WiFi or Bluetooth.</p>
+
+ <p>Work has been ongoing by Ilya Bakulin on the MMCCAM stack
+ to provide the infrastructure to be able to have SD cards
+ and SDIO devices attached side-by-side facilitating
+ FreeBSD's CAM framework.
+ Based on this excellent work over the last years,
+ SDIO support was finished earlier this year and committed
+ to FreeBSD HEAD with the intention to merge to 12 at a
+ later time.</p>
+
+ <p>Facilitating the newly available SDIO bus, work started to
+ port Broadcom's FullMAC WiFi driver. This work is still
+ in progress and expected to complete later this year.
+ With this WiFi support for the Raspberry Pi and other
+ embedded boards will become available.
+ Likewise drivers for other SDIO devices can be developed
+ now.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>BIO_DELETE support for the swap pager</title>
+
+ <contact>
+ <person>
+ <name>Doug Moore</name>
+ <email>dougm@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Alan Cox</name>
+ <email>alc@FreeBSD.org</email>
+ </person>
+ <person>
+ <name>Mark Johnston</name>
+ <email>markj@FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>An ongoing project aims to teach the swap pager to send
+ SCSI UNMAP or
+ ATA TRIM commands to the swap device when a block of swap
+ space has been
+ freed, for example when the application owning that block
+ is exiting.</p>
+
+ <p>SSDs have become commonplace and feature low latency for
+ random I/O
+ requests. This makes them appealing for use as swap
+ devices, since
+ lower latencies mean that applications spend less time
+ blocked while
+ waiting for a page-in from the swap device. To maximize
+ write
+ performance, some SSDs require the operating system to
+ send a
+ notification to the disk when a sector is no longer in
+ use; this helps
+ the disk optimize their usage of NAND flash cells. In
+ FreeBSD such a
+ notification is called a BIO_DELETE.</p>
+
+ <p>FreeBSD's UFS and ZFS filesystems have for a long time
+ been able to
+ transmit BIO_DELETE requests to the devices backing the
+ filesystem. For
+ example, for UFS this support is enabled by specifying -t
+ in newfs(8) or
+ tunefs(8)'s parameters. However, FreeBSD has historically
+ not had a
+ corresponding implementation for swap devices.</p>
+
+ <p>Thanks to Doug Moore, as of r349286 in -CURRENT and
+ r349930 in stable/12
+ swapon(8) can send BIO_DELETE to all blocks on the
+ specified device
+ immediately prior to configuring it as a swap device. This
+ is enabled
+ by specifying -E in the swapon(8) parameters, or by adding
+ the
+ "trimonce" option to the swap device's /etc/fstab entry.
+ Some
+ in-progress work on the swap pager implements online block
+ deletion, in
+ which BIO_DELETE is transmitted for blocks as they are
+ freed by
+ applications; this will hopefully be implemented in
+ FreeBSD 13.0.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='proj'>
+ <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>See the syzkaller entry in the 2019q1 quarterly report for
+ an
+ introduction to syzkaller.</p>
+
+ <p>syzkaller continues to find FreeBSD kernel bugs. A number
+ of
+ such bugs have been fixed in the past quarter, and we
+ continue
+ to investigate and fix bug reports from syzkaller. Work to
+ extend syzkaller's capabilites has progressed: Andrew
+ Turner
+ has implemented support for fuzzing the 32-bit
+ compatibility
+ layer in amd64 kernels, helping illuminate some of the
+ darker
+ corners of the kernel, and it is now possible to use bhyve
+ as
+ a VM backend to syzkaller, so it is now efficient and
+ convenient
+ to fuzz FreeBSD on FreeBSD.</p>
+
+ <p>Some planned work includes: enabling the use of ZFS as the
+ base filesystem for fuzzer VMs; extending the range of
+ system
+ calls and ioctls covered by syzkaller; enabling LLVM
+ sanitizers
+ in the kernel so as to catch more issues; and making use
+ of
+ netdump(4) to capture kernel dumps for panics found by
+ syzkaller,
+ making it much easier to diagnose bugs for which syzkaller
+ was
+ unable to find a reproducible test case.</p>
+
+ </body>
+
+ <sponsor>
+ The FreeBSD Foundation
+ </sponsor>
+
+ </project>
+
+ <project cat='proj'>
+ <title>Locking changes for vnodes during execve(2)</title>
+
+ <contact>
+ <person>
+ <name>Konstantin Belousov</name>
+ <email>kib@freebsd.org</email>
+ </person>
+ </contact>
+
+ <body>
+ <p>The execve(2) family of syscalls replaces the executing
+ image in the
+ current process. The file containing the program text,
+ data, and
+ arbitrary other pre-initialized segments for the newly
+ activated image
+ is usually called the text file. FreeBSD marks the text
+ file as such,
+ the mark is mutually exclusive with any opening of the
+ file for write.
+ In other words, file opened for write cannot be executed,
+ and text
+ file cannot be opened for write.</p>
+
+ <p>During the execve(2) syscall processing, kernel needs to
+ lock the text
+ file' vnode. This is done both to satisfy the VFS calls
+ protocol, and
+ to ensure that there is no incompatible parallel changes
+ occuring to
+ the text vnode. A vnode can be locked either in exclusive
+ mode, which
+ is mutually incompatible with any other lock acquisition,
+ or in shared
+ mode, which is only incompatible with exclusive requests,
+ but allows
+ other shared owners.</p>
+
+ <p>In principle, there is no reason why would execve(2) need
+ an exclusive
+ vnode lock, since it does not modify neither content nor
+ metadata for
+ the text vnode. The only exception is the marking of the
+ vnode as
+ text, which was done using VV_TEXT flag in v_vflag and
+ protected by
+ the vnode lock. Since we modify v_vflag, the vnode lock
+ protecting
+ the modification should be taken exclusive.</p>
+
+ <p>The end result is that execve(2)'s of the same file are
+ serialized. For
+ instance, if user runs parallel build, which executes more
+ than one
+ job for compiling, all invocation of the compiler are
+ serialized
+ during execve(2).</p>
+
+ <p>The count of opens for write is contained in other struct
+ vnode member
+ named v_writecount, which was protected by the vnode lock
+ as well.
+ Since text is mutually exclusive with an open for write, I
+ reused
+ v_writecount to indicate text references. Now, negative
+ v_writecount
+ counts the number of text references. The v_writecount
+ content is
+ literally protected by the vnode interlock, but normally
+ all mutators
+ also own vnode lock at least in the shared mode.</p>
+
+ <p>This way, we no longer need to acquire exclusive text
+ vnode lock
+ during execve(2), removing the serializing point.
+ Additional positive
+ effect is that we started to account the precise number of
+ text
+ references on the vnode. Before, we cleared VV_TEXT on the
+ last unmap
+ of the text vnode, potentially allowing obscure DoS where
+ mapping the
+ text file while it is executed prevented writes until the
+ mapping is
+ destroyed. Now we mark the mappings for text explicitly in
+ the
+ vm_map_entry and dereference v_writecount by +1 when such
+ entry is
+ unmapped.</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,
+ including adding a BCM58712 quirk to GICv2m driver</li>
+
+ <li>BNXT Ethernet support: sys/dev/bnxt.c driver has been
+ extended to support
+ the BCM58700 variant, and the iflib was made to work
+ without IO cache coherency</li>
+ </ul>
+
+ <p>
+ In progress:</p>
+
+ <ul>
+ <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>
+
+ </body>
+
+ <sponsor>
+ Juniper Networks, Inc
+ </sponsor>
+
+ </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>Already completed:</p>
+
+ <ul>
+ <li>Platform base support (ramp-up multi-user SMP operation
+ with UART)</li>
+
+ <li>SATA 3.0</li>
+ </ul>
+
+ <p>
+ In progress:</p>
+
+ <ul>
+ <li>USB3.0</li>
+
+ <li>SD/MMC</li>
+
+ <li>I2C</li>
+ </ul>
+
+ <p>
+ Todo:</p>
+
+ <ul>
+ <li>Ethernet support</li>
+
+ <li>GPIO</li>
+
+ <li>QSPI</li>
+
+ <li>Upstreaming of developed features. This work is expected
+ to
+ be submitted/merged to HEAD in the Q4 of 2019.</li>
+ </ul>
+
+ </body>
+
+ <sponsor>
+ Alstom Group
+ </sponsor>
+
+ </project>
+
+ <project cat='third'>
+ <title>Aberdeen Hackathon</title>
+
+ <body>
+ <p>At BSDCam in Cambridge last year we had a discussion to
+ create a template
+ Hackathon in the same way we have a template for
+ Devsummits. To test out the
+ idea I was convinced (I swear tricked is the correct word)
+ to host a Hackathon
+ in Aberdeen.</p>
+
+ <p>As a project I think we benefit a lot from hackathons, but
+ they do take a
+ little organisation. The worst part of this is dealing
+ with getting money from
+ attendees so you can pay for events. I spoke with Deb
+ Goodkin from the
+ foundation at BSDCam and we arranged to use their new
+ EventBrite based system
+ to handle ticketing.</p>
+
+ <p>Overall this system made it straight forward for attendees
+ to register and get
+ me their details and requirements. After the event the
+ expenses were then
+ recouped from the foundation. This was much easier than me
+ putting together a
+ custom system or even setting up and using EventBrite
+ myself.</p>
+
+ <p>The hackathon went well, you can read in Benedict and
+ Kristof's reports that
+ follow, but it was less well attended than I originally
+ expected.</p>
+
+ <p>For hackers planning future hackathons remember to take
+ heed of common national
+ holidays (we could have planned the event to not land at
+ Easter) and expect
+ major geopolitical events to make things unpredictable (we
+ knew Brexit would do
+ something, but not when).</p>
+
+ <p>I need to thank the University of Aberdeen for providing
+ the location for the
+ Hackathon and to encourage you to run a hackathon where
+ you are. The next one
+ should be in your home town.</p>
+
+ <p>Benedict Reuschling</p>
+
+ <p>The hackathon in Aberdeen was happening in the week of
+ Easter at the University
+ of Aberdeen. Although only Kristof Provost (kp@) and
+ myself joined our host Tom
+ Jones, I still consider it a productive week for us. The
+ overall theme of the
+ hackathon was networking and each of us provided something
+ towards that goal
+ (be it PRs, submitting unfinished work, or other bits and
+ pieces). We got
+ together the night of Tuesday, April 16 over dinner and
+ talked about what our
+ plans were for the week.</p>
+
+ <p>Kristof and I had talked at AsiaBSDcon when I took his
+ tutorial about Testing
+ in FreeBSD that we should add a chapter about it in the
+ developers handbook. We
+ also used our first meeting to synchronize each other
+ about the latest news in
+ FreeBSD from our developers viewpoint.</p>
+
+ <p>The next day, we met up at the Frazer Noble building where
+ the hackathon was
+ taking place. It was one of the newer buildings on campus,
+ nicely integrated
+ into the older houses of the city. Since we were only a
+ handful, we sat in
+ Tom's office for the hackathon, which had plenty of room.
+ He also showed us the
+ room where we are supposed to be having the hackathon if
+ we were more people
+ and Tom gave us a little tour. Working in a university
+ myself, I'm always
+ interested in how other education organizations are
+ structured and the rooms
+ and equipment they provide for learning. Overall, my
+ impression was that there
+ is a good amount of space and equipment available, which
+ we could have used in
+ the hackathon.</p>
+
+ <p>After returning, we decided to use a special tag in the
+ commits we would be
+ doing to identify them as coming from this hackathon. We
+ chose "Event:" for it
+ as it is a general enough term to be used at other events
+ like conferences,
+ too. The "Sponsored by:" line we used in the past is more
+ for companies or
+ individuals sponsoring certain features, so I created a
+ review to add this line
+ to the committers guide.</p>
+
+ <p>Kristof had a couple of changes to the pf chapter in the
+ FreeBSD handbook for
+ me, so I started going through those. I created a review
+ for him and the commit
+ was made there and then, making use of the short feedback
+ cycle. Originally, we
+ thought about bringing in people via hangouts, but then
+ resolved to contact
+ people via our usual IRC channel if we needed their input.</p>
+
+ <p>Kristof and Tom worked on some network specific stuff,
+ whereas I started work
+ on creating an initial draft for the testing chapter. We
+ would occasionally
+ start talking about something and then return to our work
+ in silence. If we
+ needed to coordinate or had questions, we simply asked and
+ could continue once
+ we got our answer. This provided a nice atmosphere to work
+ in. I tackled some
+ doc PRs while Kristof found a bug in pf and fixed it.</p>
+
+ <p>The afternoons were spent at different locations within
+ walking distance. Tom
+ made sure we got a good impression on how it is to be a
+ student and that there
+ is both taste and variety of food available. In the
+ evenings, Tom drove us into
+ town to have dinner at various restaurants over the week.</p>
+
+ <p>Aberdeen has a lot to offer as a city. Starting from the
+ second day, Kristof
+ and I would meet up at my hotel, which was close to the
+ Aberdeen beach and walk
+ along it to the University. According to Tom, it is
+ possible to see Dolphins
+ when the weather is right and the gulf stream provides the
+ city with enough
+ warmth that the winters aren't as bad as you'd think this
+ far up north.</p>
+
+ <p>Tom also gave us a tour of the zoological department of
+ the university, which
+ offered a beautiful garden with various plants and trees,
+ as well as a museum
+ with zoological specimen. This offered a great spot for
+ photographs and to
+ unwind a bit from the technical discussions we've had. Tom
+ also had t-shirts
+ made for the event, which are already rare collectors
+ items.</p>
+
+ <p>I had to return on Sunday, so Tom took us on a tour of the
+ Scottish highlands
+ in his car the day before. We stopped at a couple of
+ places to take pictures
+ and Tom would explain at lot to us having lived there all
+ his life. We came to
+ Stonehaven and had fish and chips there from a take-out
+ restaurant that had a
+ lot of awards for sustainable fishing. This was certainly
+ a highlight for the
+ week and even then, we couldn't stop talking about FreeBSD
+ and networking.</p>
+
+ <p>Although more people would maybe have produced more
+ output, the three of us
+ were certainly productive as a small group. It also made
+ planning and
+ coordination easier and more flexible. Tom Jones had done
+ a lot of preparation
+ and was an excellent guide. I would encourage him to host
+ another such
+ hackathon in the future and hope that next time, more
+ people will take a trip
+ to Aberdeen to spend some time hacking on FreeBSD</p>
+
+ <p>Kristof Provost</p>
+
+ <p>While I’d been to Scotland before I’d never seen Aberdeen.
+ It’s a charming
+ city, and I enthusiastically recommend visiting.</p>
+
+ <p>I arrived a little while after Benedict, but made it to my
+ hotel easily, and
+ turned up in time to join Benedict and Tom for dinner.</p>
+
+ <p>Despite being small (or perhaps because of it), the
+ hackathon was remarkably
+ productive. Benedict and I went through the pf
+ documentation in the handbook,
+ so that Benedict could rework and improve it. (Benedict’s
+ doing the work, but
+ I’m going to take credit anyway.)</p>
+
+ <p>Tom and I looked at the GSoC proposals and tried to find
+ potential mentors for
+ two promising proposals. Both of us are candidate mentors
+ as well. We should
+ know soon if our students are awarded slots.</p>
+
+ <p>Tom also proposed a patch to eliminate RFC 2675 IPv6
+ Jumbograms. It has my
+ enthusiastic support.</p>
+
+ <p>I managed to look at a couple of open pf issues:</p>
+
+ <ul>
+ <li>pfctl’s interface_group() function checks if a name is an
+ interface or an interface group. It still thought
+ that interface names always ended with a number,
+ but this assumption has been wrong for several
+ years now. That’s fixed in <a
+ href="https://svnweb.freebsd.org/changeset/base/346370">r346370</a>.</li>
+
+ <li>The DIOCRSETTFLAGS ioctl() misused copyin() (It held a
+ lock calling it), which could result in panics.</li>
+
+ <li>That previous issue was actually discovered by my local
+ instance of syzcaller, which I’d set up to add pf
+ support to it. That support has now been merged,
+ so we may see more issues detected by syzcaller
+ soon.</li>
+
+ <li>Also for the DIOCRSETTFLAGS problem I extended the pf
+ tests to check for this issue.</li>
+
+ <li>The pf tests will now fail if the pft_set_rules call fails
+ to set the rules. That didn’t actually cause
+ issues yet, but it’ll make debugging tests
+ slightly easier, and they may catch more problems
+ now.</li>
+ </ul>
+
+ <p>
+ On Saturday Tom took us out to discover some of the pretty
+ bits of Scotland. It
+ turns out there are a lot of them. I can’t really do it
+ justice, but Tom has a
+ promising career at the Scottish tourism board when this
+ computers fad blows
+ over.</p>
+
+ <p>On my way home I passed through Oslo, and took the
+ opportunity to meet with
+ (have lunch with) two of the EuroBSDCon local organisers.
+ EuroBSDCon is filling
+ up fast, make sure to register now to secure your place!</p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>Bring more Security Intelligence to FreeBSD</title>
+
+ <contact>
+ <person>
+ <name>Michael Muenz</name>
+ <email>m.muenz@gmail.com</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/stamparm/maltrail">Maltrail - distributed Malware detection</url>
+ <url href="https://wazuh.com/">Wazuh - thread detection and incident response</url>
+ </links>
+
+ <body>
+ <p>To bring more Security Intelligence we maintain the
+ FreeBSD port
+ of <tt>zmaltail</tt>. This open source project based on
+ Python can act
+ as a sensor and/or as a central server. It listens in
+ defined ports
+ or protocols and compares IP addresses and domains against
+ static
+ and dynamic feeds, contributed by the community.</p>
+
+ <p>As you can install this piece of software on multiple
+ firewalls
+ and let them send to a central server, you are able to
+ detect attacks
+ and compromises very fast. Within Q2 we updated the port
+ to the latest
+ version and are constantly in contact with the core
+ developer
+ (also co-author of <tt>SQLmap</tt>) to bring out new
+ features.</p>
+
+ <p>The second project we are currently trying to add as a
+ port is <tt>Wazuh</tt>.
+ Wazuh is a fork of <tt>Ossec</tt> which is already in the
+ ports tree.
+ Compared to Ossec, Wazuh has some intelligent addition
+ like full
+ <tt>ELK-Stack</tt> integration with own apps and
+ dashboards.</p>
+
+ <p>With Wazuh installed on your webserver, or even on your
+ windows desktop
+ you can monitor file integrity or log files for most kind
+ of attacks.
+ Active response features let you e.g. send API calls to
+ your firewalls
+ to dynamically block this offender.</p>
+
+ <p>As Wazuh offers a complete ELK-Stack you can use it also
+ as a central
+ logging solution for better security insights into your
+ network.</p>
+
+ </body>
+
+ <sponsor>
+ m.a.x. Informationstechnologie AG
+ </sponsor>
+
+ </project>
+
+ <project cat='third'>
+ <title>nsysctl 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/nsysctl">gitlab.com/alfix/nsysctl</url>
+ <url href="https://www.freshports.org/sysutils/nsysctl/">sysutils/nsysctl port</url>
+ <url href="https://alfix.gitlab.io/bsd/2019/02/19/nsysctl-tutorial.html">Tutorial</url>
+ </links>
+
+ <body>
+ <p>The <tt>nsysctl</tt> utility is a <tt>/sbin/sysctl</tt>
+ clone, to get or set the kernel
+ state, supporting <tt>libxo</tt> and extra options.</p>
+
+ <p><programlisting>
+ nsysctl [--libxo=opts [-r tagname]]<br/>
+ [-DdFGgIilmNpqTt[V|v[h[b|o|x]]]Wy]<br/>
+ [-e sep] [-B &lt;bufsize&gt;] [-f filename]<br/>
+ name[=value[,value]] ...<br/>
+ nsysctl [--libxo=opts [-r tagname]]<br/>
+ [-DdFGgIlmNpqTt[V|v[h[b|o|x]]]Wy]<br/>
+ [-e sep] [-B &lt;bufsize&gt;] -A|a|X<br/>
+</programlisting></p>
+
+ <p>You could use <tt>nsysctl</tt> to explore the sysctl MIB
+ showing the value and the
+ info of an object. The output is explicitly indicated by
+ the options and is
+ printed via <tt>libxo</tt> in human and machine readable
+ formats, moreover some value
+ is parsed to display it in a structured mode (e.g.,
+ <tt>vm.phys_free</tt>).
+ The support for <tt>efi_map_header</tt> was added but it
+ is untested, someone could
+ help by trying it via <tt>machdep.efi_map</tt>.</p>
+
+ <p>Please refer to the tutorial for a more thorough
+ description.</p>
+
+ </body>
+
+ </project>
+
+ <project cat='third'>
+ <title>libvdsk - QCOW2 implementation</title>
+
+ <contact>
+ <person>
+ <name>Sergiu Weisz</name>
+ <email>sergiu121@gmail.com</email>
+ </person>
+ <person>
+ <name>Marcel Molenaar</name>
+ <email>marcel@freebsd.org</email>
+ </person>
+ <person>
+ <name>Marcelo Araujo</name>
+ <email>araujo@freebsd.org</email>
+ </person>
+ <person>
+ <name>Mihai Carabas</name>
+ <email>mihai@freebsd.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://github.com/xcllnt/libvdsk">Github - libvdsk repo</url>
+ </links>
+
+ <body>
+ <p>Add support for using QCOW in bhyve using the libvdsk
+ library. Libvdsk was used
+ to substitute the regular disk operations from bhyve with
+ a call to libvdsk
+ which will in turn call the disk-specific handler for the
+ operation.</p>
+
+ <p>To use this feature one has to install the libvdsk-enabled
+ bhyve version along
+ with libvdsk from the libvdsk repo linked above.</p>
+
+ <p>New features added:</p>
+
+ <ul>
+ <li>Extend libvdsk to make it easier to implement new formats</li>
+
+ <li>Improve read/write performance and stability</li>
+
+ <li>Add support for Copy-On-Write</li>
+ </ul>
+
+ <p>
+ Future tasks:</p>
+
+ <ul>
+ <li>Integrate libvdsk in bhyve</li>
+ </ul>
+
+ <sponsor>
+ Matthew Grooms
+ </sponsor>
+
+ </body>
+
+ </project>
+
+</report>

File Metadata

Mime Type
text/plain
Expires
Thu, Oct 9, 7:33 AM (22 h, 24 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
23488773
Default Alt Text
D21381.diff (74 KB)

Event Timeline