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 @@
+
+
+
+
+
+
+
+ This is a draft of the %%START%%–%%STOP%% %%YEAR%%
+ status report. Please check back after it is finalized, and
+ an announcement email is sent to the &os;-Announce mailing
+ list.
The %%NUM%% quarter of %%YEAR%% was another productive quarter for + the &os; project and community. [...]
+ +Thanks to all the reporters for the excellent work!
+ +The deadline for submissions covering the period from %%STARTNEXT%% + to %%STOPNEXT%% %%YEARNEXT%% is %%DUENEXT%%, %%YEARNEXT%%.
+ ?> + + +Entries from the various official and semi-official teams, + as found in the Administration + Page.
+Projects that span multiple categories, from the kernel and userspace + to the Ports Collection or external projects.
+Updates to kernel subsystems/features, driver support, + filesystems, and more.
+Updating platform-specific features and bringing in support + for new hardware platforms.
. +Changes affecting the base system and programs in it.
+Changes affecting the Ports Collection, whether sweeping + changes that touch most of the tree, or individual ports + themselves.
+Noteworthy changes in the documentation tree or new external + books/documents.
+Objects that defy categorization.
+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.
+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.
+ +During the first quarter of 2019, the FreeBSD Release + Engineering team + published the initial schedule for the upcoming the + 11.3-RELEASE.
+ +FreeBSD 11.3-RELEASE will be the fourth release from the + stable/11 + branch, building on the stability and reliability of + 11.2-RELEASE. + FreeBSD 11.3-RELEASE is currently targed for release in + early July, 2019.
+ +Additionally throughout the quarter, several development + snapshots builds + were released for the head, stable/12, + and stable/11 branches.
+ +Much of this work was sponsored by the FreeBSD Foundation.
+ + + +As always, below is a summary of what happened in the + Ports Tree during the + last quarter.
+ +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.
+ +During the last quarter, we welcomed Kai Knoblich (kai@) + and said goodbye to + Matthew Rezny (rezny@).
+ +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.
+ +During the last quarter, antoine@ ran 30 exp-runs for + package updates, moving + from GNU ld to LLVM ld, and switching clang to DWARF4.
+ + + +The FreeBSD Core Team is the governing body of FreeBSD.
+ +Core initiated a Release Engineering Charter + Modernization working + group. The purpose of the working group is to present (to + Core) a + modernized version of the Release Engineering + Charter and a first + version of a new Release Engineering Team Operations + Plan. The + group hopes to complete its goals and dissolve by + 2019-06-30.
+ +The Core Team invites all members of the FreeBSD community + to + complete the 2019 FreeBSD Community Survey.
+ +https://www.research.net/r/freebsd2019
+ +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)
+ +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.
+ +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.
+ +The FreeBSD Foundation is a 501(c)(3) non-profit + organization dedicated to + supporting and promoting the FreeBSD Project and community + worldwide. + Funding comes from individual and corporate donations and + is used to fund + and manage software development projects, conferences and + developer summits, + and provide travel grants to FreeBSD contributors.
+ +The Foundation purchases and supports hardware to improve + and maintain + FreeBSD infrastructure and provides resources to improve + security, + quality assurance, and release engineering efforts; + publishes + marketing material to promote, educate, and advocate for + the FreeBSD Project; + facilitates collaboration between commercial vendors and + FreeBSD developers; + and finally, represents the FreeBSD Project in executing + contracts, + license agreements, and other legal arrangements that + require + a recognized legal entity.
+ +Here are some highlights of what we did to help FreeBSD + last quarter:
+ +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.
+ +Partnerships and Commercial User Support
+ +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.
+ +Fundraising Efforts
+ +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 + donation + to help us continue and increase our support for FreeBSD + at: + www.FreeBSDfoundation.org/donate/.
+ +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!
+ +OS Improvements
+ +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.
+ +Over the quarter there were 241 commits from nine + Foundation-sponsored staff + members and grant recipients.
+ +We kicked off or continued the following projects last + quarter:
+ ++ Having software developers on staff has allowed us to jump + in and + work directly on projects to improve FreeBSD like:
+ ++ Continuous Integration and Quality Assurance
+ +The Foundation provides a full-time staff member who is + working on improving + our automated testing, continuous integration, and overall + quality assurance + efforts.
+ +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 + CI + weekly report + on the freebsd-testing@ mailing list.
+ +See the FreeBSD CI section of this report for more + information.
+ +Release Engineering
+ +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.
+ +During the first quarter of 2019, the FreeBSD Release + Engineering team + continued providing weekly development snapshots for + 13-CURRENT, 12-STABLE, + and 11-STABLE.
+ +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.
+ +The upcoming + 11.3-RELEASE + schedule + can be found at: + https://www.freebsd.org/releases/11.3R/schedule.html
+ +FreeBSD 11.3 is currently targeted for final release in + early July 2019.
+ +Please see the FreeBSD Release Engineering Team section of + this quarterly + status report for additional details surrounding the above + mentioned work.
+ +Supporting FreeBSD Infrastructure
+ +The Foundation provides hardware and support to improve + FreeBSD infrastructure. Last quarter, we continued + supporting FreeBSD hardware located + around the world.
+ +FreeBSD Advocacy and Education
+ +A large part of our efforts are dedicated to advocating + for the Project. + This includes promoting work being done by others with + FreeBSD; producing + advocacy literature to teach people about FreeBSD and help + make the path to + starting using FreeBSD or contributing to the Project + easier; and attending + and getting other FreeBSD contributors to volunteer to run + FreeBSD events, + staff FreeBSD tables, and give FreeBSD presentations.
+ +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.
+ +Check out some of the advocacy and education work we did + last quarter:
+ ++ We continued producing FreeBSD advocacy material to help + people promote + FreeBSD around the world.
+ +Read more about our conference adventures in the + conference recaps and trip + reports in our + monthly + newsletters.
+ +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 + www.FreeBSDfoundation.org/journal/.
+ +You can find out more about events we attended and + upcoming events at + www.FreeBSDfoundation.org/news-and-events/.
+ +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.
+ +Legal/FreeBSD IP
+ +The Foundation owns the FreeBSD trademarks, and it is our + responsibility to + protect them. We also provide legal support for the core + team to investigate + questions that arise.
+ +Go to www.FreeBSDfoundation.org + to find out + how we support FreeBSD and how we can help you!
+ + + +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.
+ +Starting from this quarter, we started to publish CI + weekly report at + freebsd-testing@ + mailing list. The archive is available at + https://hackfoldr.org/freebsd-ci-report/
+ +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.
+ +We published the + draft + FCP for CI policy + and are ready to accept comments.
+ +Please see freebsd-testing@ related tickets for more + information.
+ +Work in progress:
+ +ASLR
+ +The ASLR (Address Space Layout Randomization) patch from + review + D5603 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.
+ +KPTI per-process control
+ +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.
+ +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.
+ +Feature-control bits
+ +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.
+ +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.
+ +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..
+ +It is expected that a tool to manipulate the mask will be + provided + shortly, see review + D19290.
+ + + + + +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 Pinebook.
+ +The following updates were performed on the AXP803 driver:
+ +The Semihalf team continued working on FreeBSD support for + the + Broadcom + BCM5871X SoC series
+ +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.
+ +Completed since the last update:
+ ++ In progress:
+ ++ Todo:
+ +Three themes for Capsicum work were:
+ ++ 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.
+ +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 lstat to the Casper service.
+ +Furthermore, openrsync highly depends on the fts + API. We spend + some time in optimizing fts and making it sandbox + friendly by + introducing fts_openat function and removing the + need to change the + working directory to traverse the paths. The changes to + the fts API + are now in the tests phase.
+ +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 strings + is now sandboxed as a + result.
+ +We also sandboxed rtsol, rtsold, and + savecore.
+ +We host biweekly Capsicum calls. The notes from the + meetings are published + in FreeBSD's + Capsium + meeting repository + on GitHub. + If you would like to join the call do not hesitate to send + us an email.
+ + + +Several changes where made to the C runtime which + generally improves + the environment provided to an application.
+ +Fix for libraries with initial exec TLS mode
+ +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.
+ +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.
+ +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.
+ +Another issue that somewhat mitigates mis-use of the mode + is the + DF_STATIC_TLS 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.
+ +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.
+ +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.
+ +Use rtld malloc in libthr
+ +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.
+ +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.
+ +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.
+ +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.
+ +Destructors order bug
+ +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 + __attribute__(((destructor))).
+ +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.
+ +Solution is to register rtld atexit(3) handler before main + binary init + functions are called, using new internal ABI + __libc_atexit() function.
+ +It is amusing that the bug was not noticed for so many + years.
+ + + + + +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.
+ +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.
+ +To do:
+ ++ 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 + r345371 + and the addition of a missing bus release method to the + nexus module + for aarch64 + r345373. + With these changes, the ENA driver can run on A1 instances + without + any known issues.
+ + + + + +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 + buggy + and out-of-date. Our implementation is about 11 years + behind.
+ +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.
+ + + + + +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.
+ +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.
+ +This will clean up zombie programs and duplicated zlib + code. + This will also make future zlib version updates easier.
+ +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.
+ +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.
+ +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.
+ +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.
+ +To do:
+ ++ Special thanks to sjg and Juniper for fruitful cooperation + around + Veriexec and the libsecureboot development.
+ + + + + +In FreeBSD-HEAD and 12.0 the default FreeBSD system linker + (i.e., /usr/bin/ld) 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.
+ +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 -fPIC + 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.
+ +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).
+ +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 -znotext 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.
+ +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.
+ +Tasks:
+ +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.
+ +Following updates done in mlx5 drivers:
+ +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.
+ +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.
+ +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.
+ +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.
+ +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.
+ +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.
+ + + + + +The TrueOS project has been working on a Package Base + implementation, + and is pleased to issue its first [CFT to the FreeBSD + community]https://lists.freebsd.org/pipermail/freebsd-pkgbase/2019-April/000396.html.
+ +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]https://github.com/freebsd/poudriere/pull/664, + as well + as some minor ports enhancements, the first which is + [currently in + review]https://reviews.freebsd.org/D20055. + For more information + on the current status, please refer to the FAQ page.
+ +Additionally there will be a [working-group at BSDCan + 2019]https://wiki.freebsd.org/DevSummit/201905/PackageBase, + and + we encourage porters to attend and join the discussion.
+ + + + + +Work has continued on RISC-V port in the past quarter.
+ +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.
+ +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.
+ +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.
+ +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.
+ + + + + +Ports activity in this quarter where:
+ ++ Work in progress, the branches are available in the GNOME + development + repo, see the link above.
+ ++ People who are willing to contribute can find us on + #freebsd-gnome + on freenode.
+ + + +The two biggest accomplishements this quarter were:
+ ++ 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.
+ +All the kde@ maintained ports (including cmake) have been + kept up + to date with their releases.
+ +The plans for the next quarter are in no particular order
+ ++ 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.
+ + + + + +Port: devel/libsysctlmibinfo
+ +The sysctl() 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 + /sbin/sysctl, + example:
+ +``` + % sysctl -d kern.ostype + kern.ostype: Operating system type + % sysctl -t kern.ostype + kern.ostype: string + ```
+ +Primarily sysctlmibinfo wraps the undocumented + kernel interface + and provides an easy C API: sysctlmif_name(), + sysctlmif_description(), + sysctlmif_info(), + sysctlmif_label(), + sysctlmif_nextnode() and + sysctlmif_nextleaf(), to retrieve + the info of a 'property'.
+ +Moreover sysctlmibinfo provides a high level API: + defines a + struct sysctlmif_object and has some function: + sysctlmif_filterlist(), + sysctlmif_grouplist() and + sysctlmif_tree(), to build lists and trees of + objects.
+ +You can use this library to quickly build a custom + sysctl utility. + For example, the core of deskutils/sysctlview (a + graphical explorer + for the sysctl MIB Tree) is just a call to + sysctlmif_tree() and + a visit to the resulting tree to show its + sysctlmif_object nodes.
+ +Note, actually a 'property' is an OID of the sysctl MIB, + it is + implemented by a struct sysctl_oid defined in + sys/sysctl.h.
+ + + +Port: deskutils/sysctlview
+ +The FreeBSD's kernel maintains a Management Information + Base where + the objects are properties to tuning the system using the + sysctl() syscall and the /sbin/sysctl + utility. The sysctlview + utility is a "graphical sysctl MIB explorer", it depends + on gtkmm + (to build a GUI) and sysctlmibinfo (to retrieve + the info from the + kernel).
+ +The version 1.0 provides two "TreeView":
+ ++ The rows are "clickable" to display others info (e.g., + 'label'). + Currently sysctlview can show numeric and string + values, the + support for some opaque value will be added in the future.
+ + + +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.
+ +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]https://syzkaller.appspot.com/freebsd + was recently added. + Subscribe to the + syzkaller-freebsd-bugs + Google Group to receive notifications for newly discovered + bugs.
+ +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.
+ +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 + PR + for the + implementation.
+ +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.
+ + + + + +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.
+ +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 + libarchive + change + to support 64-bit archives followed by + change to + FreeBSD's ar + to add 64-bit support.
+ +Gerald later looked at a number of freebsd-update + issues in FreeBSD's + bugzilla database, and submitted many fixes. Around a + dozen have been + committed to FreeBSD, and more are in review.
+ +Gerald also worked on the + FreeBSD + Foundation's hardware continuous integration + 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.
+ +For his final project Gerald intends to write a device + driver for the + Microchip + LAN743x PCIe NIC.
+ +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 readelf + (from the + ELF + Tool Chain project).
+ +Bora developed a + tool 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.
+ +Bora continued investigating security topics, looking at + applying + Capsicum + sandboxing to + Kristaps' BSD licensed rsync implementation, + openrsync. + This work required first implementing + fileargs_lstat + support in cap_fileargs + (which as now been committed) as well as changes to the + fts directory hierarchy routines (which have not + yet been committed to + FreeBSD).
+ +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.
+ + + + + +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.
+ +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.
+ +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.
+ +Future tasks:
+ +