Index: head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml (revision 46554) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml (revision 46555) @@ -1,2014 +1,2074 @@ January-March 2015
Introduction

This is a draft of the January–March 2015 status report. Please check back after it is finalized, and an announcement email is sent to the &os;-Announce mailing list.

This report covers &os;-related projects between January and March 2015. This is the first of four reports planned for 2015.

The first quarter of 2015... was a very busy and productive time.

Thanks to all the reporters for the excellent work!

The deadline for submissions covering the period from April to June 2015 is July 7th, 2015.

team &os; Team Reports proj Projects kern Kernel arch Architectures bin Userland Programs ports Ports doc Documentation misc Miscellaneous Address Space Layout Randomization (ASLR) Shawn Webb shawn.webb@hardenedbsd.org Oliver Pinter oliver.pinter@hardenedbsd.org HardenedBSD ASLR Call For Testing FreeBSD Code Review of ASLR

Address Space Layout Randomization (ASLR) is a computer security technique that aids in mitigating low-level vulnerabilities such as buffer overflows. ASLR randomizes the memory layout of running applications to prevent an attacker from knowing where a given exploitable vulnerability lies in memory.

We have been working hard the last few months to ensure the robustness of our ASLR implementation. We have written a helpful manpage. We have updated the patch on FreeBSD's code review system (Phabricator). Our ASLR implementation is in heavy use by the HardenedBSD team in production environments and is performing robustly.

The next task is to compile the base system applications as Position-Independent Executables (PIEs). In order for ASLR to be effective, applications must be compiled as PIEs. It is likely that this part will take a long time to accomplish, given the complexity surrounding building the libraries in the base system. Even if applications are not compiled as PIEs, having ASLR available still helps those applications (like HardenedBSD's secadm) which force compilation as PIE for themselves.

SoldierX

Test our patch against 11-CURRENT.

For &os; committers: work with us to get this merged into &os;.

 Xfce on &os; &os; Xfce Team xfce@FreeBSD.org

Xfce is a free software desktop environment for Unix and Unix-like platforms, such as &os;. It aims to be fast and lightweight, while still being visually appealing and easy to use.

This quarter was an exciting time for the Xfce Team. We imported the Xfce desktop environment 4.12 into the ports tree, after more than two years of development.

Overall, we have updated the following ports:

At the same time we switched to the USES framework, and a new plugin has been added, called audio/xfce4-pulseaudio-plugin.

We also follow the unstable releases (available in our experimental repository) of:

The following documentation patches are ready:

Work on support for Compact Disc Digital Audio (CD-DA) in multimedia/xfce4-parole.

Add a new property (through xfconf-query) in order to allow users to change the greyscale value of quicklaunch icons in x11/xfce4-dashboard (this feature is only available in the unstable release).

 Lua boot loader Rui Paulo rpaulo@FreeBSD.org Pedro Souza pedrosouza@FreeBSD.org Wojciech Koszek wkoszek@FreeBSD.org

The Lua boot loader project is in its final stage and it can be used on x86 already. The aim of this project is to replace the Forth boot loader with a Lua boot loader. All the scripts were re-written in Lua and are available in sys/boot/lua. Once all the Forth features have been tested and once the boot menus look exactly like in Forth, we will start merging this project to &os; HEAD. Both loaders can co-exist in the source tree with no problems because a pluggable loader functionality was introduced for this purpose.

The project was initially started by Wojciech Koszek, and Pedro Souza wrote most of the Lua code last year in his Google Summer of Code project.

To build a Lua boot loader just use:

WITH_LUA=y
 WITHOUT_FORTH=y

Feature/appearance parity with Forth.

Investigate use of floating point by Lua.

Test the EFI Lua loader.

Test the U-Boot Lua loader.

Test the serial console.

 More Michael Lucas &os; books Michael Lucas mwlucas@michaelwlucas.com

The &os; storage books are proceeding slower than expected. This is a complex project.

It appears that ZFS will be a two-book topic. The first book will cover basic ZFS, while the second will cover advanced cases like live and cold replication, sharing, performance, and using ZFS on top of less common GEOM providers. More details can be found in the links section.

Allan Jude (allanjude@) is co-authoring the ZFS books. Little did he know of the magnitude of the task ahead of him when he signed up....

 Opaque ifnet Gleb Smirnoff glebius@FreeBSD.org Project wiki page

The project is to design a new KPI for network drivers that would allow for the network stack to evolve, without breaking compatibility with older drivers. The core idea is to hide struct ifnet from drivers, thus the project has the name "opaque ifnet". However, the project will include more changes than just hiding the struct's definition.

At present, the new KPI has been prototyped, most important parts of network stack have been modified appropriately, and several drivers have been converted to new KPI.

The project needs more manpower, since there are many network drivers in the tree, with a total of 245 sites where a struct ifnet is allocated.

Netflix

Convert more drivers.

 Ports Collection Frederic Culot portmgr-secretary@FreeBSD.org Port Management Team portmgr@FreeBSD.org

As of the end of Q1 the ports tree holds almost 25,000 ports, and the PR count is just over 1,500. The tree saw more activity than during the previous quarter, with almost 7,000 commits performed by 163 active committers. The number of problem reports closed also increased by about 20%, with nearly 2,000 PRs closed!

In Q1 two new developers were granted a ports commit bit (jbeich@ and brd@) and one was taken in for safekeeping (rafan@, on his request).

On the management side, decke@ decided to step down from his portmgr duties in February. No other changes were made to the team during Q1.

This quarter also saw the release of the first quarterly branch of the year, 2015Q1. On this branch, 140 changes were applied by 35 committers.

On the QA side, 29 exp-runs were performed to validate sensitive updates or cleanups.

As during the previous quarter a tremendous amount of work was done on the tree to update major ports and to close even more PRs than in 2014 Q4. However, we sometimes lag behind with regards to documentation, so volunteers are welcome to help on this important task.

 bhyve Peter Grehan grehan@FreeBSD.org Neel Natu neel@FreeBSD.org John Baldwin jhb@FreeBSD.org Tycho Nightingale tychon@FreeBSD.org Allan Jude freebsd@allanjude.com Alexander Motin mav@freebsd.org bhyve FAQ and talks

bhyve is a hypervisor that runs on the FreeBSD/amd64 platform. At present, it runs FreeBSD (8.x or later), Linux i386/x64, OpenBSD i386/amd64, and NetBSD/amd64 guests. Current development is focused on enabling additional guest operating systems and implementing features found in other hypervisors.

Peter Grehan did a status update at bhyvecon 2015 in Tokyo. The slides are available at http://bhyvecon.org/bhyvecon2015-Peter.pdf

Mihai Carabas presented the results of his GSoC project on implementing instruction caching in bhyve at AsiaBSDCon 2015 in Tokyo. The slides are available at http://people.freebsd.org/~neel/bhyve/bhyve-cache-emul-slides.pdf

A number of improvements were made to bhyve this quarter:

Improve documentation.

bhyveucl is a script for starting bhyve instances based on a libUCL config file. More information is at https://github.com/allanjude/bhyveucl

Add support for virtio-scsi.

Flexible networking backends: wanproxy, vhost-net.

Move to a single process model, instead of bhyveload and bhyve.

Support running bhyve as non-root.

Add filters for popular VM file formats (VMDK, VHD, QCOW2).

Implement an abstraction layer for video (no X11 or SDL in the base system).

Suspend/resume support.

Live Migration.

Nested VT-x support (bhyve in bhyve).

Support for other architectures (ARM, MIPS, PPC).

 Jenkins Continuous Integration for &os; Craig Rodrigues rodrigc@FreeBSD.org Jenkins Administrators jenkins-admin@FreeBSD.org &os; Testing freebsd-testing@FreeBSD.org Jenkins CI server in &os; cluster Cloud9ers Ahmed Kamal Ahmed's contributions to SaltStack Kyua turns parallel Jenkins Multiple SCM's plugin fixes GCC 4.9 problems External Toolchain Support

The Jenkins Continuous Integration and Testing project has been helping to improve the quality of &os;. Since the last status report, we have quickly found commits which caused build breakage or test failures. &os; developers saw these problems and quickly fixed them. Some of the highlights include:

Set up more builds based on different architectures.

Improve the maintenance of nodes in the Jenkins cluster using devops frameworks such as Saltstack.

People interested in helping out should join the freebsd-testing@FreeBSD.org list.

 Clang, llvm and lldb updated to 3.6.0 Dimitry Andric dim@FreeBSD.org Ed Maste emaste@FreeBSD.org Roman Divacky rdivacky@FreeBSD.org Davide Italiano davide@FreeBSD.org LLVM 3.6.0 Release Notes Clang 3.6.0 Release Notes

Just before the end of the quarter, we have updated clang, llvm and lldb in base to 3.6.0 release. These all contain numerous improvements; please see the linked release notes for more detailed information.

We have also imported a newer snapshot of compiler-rt, with better support for Address Sanitizer and Undefined Behavior Sanitizer, and arm64 runtime support routines. With the updated clang, llvm, and compiler-rt, we now support the Address and Undefined Behavior Sanitizers in the base system toolchain.

Like the 3.5.0 release, these components require C++11 support to build. At this point, FreeBSD 10.0 and later provide that support, at least on x86.

It is still unclear whether we will be able to MFC this to any stable branches, due to the difficulty it will introduce for upgrading from a system without C++11 support, either older releases or architectures still using gcc.

In the lld-import branch, we have also imported a recent snapshot of lld, a linker produced by the LLVM project. This is a very preliminary effort of making it available as a system linker.

Thanks to Ed Maste, Roman Divacky, Andrew Turner and Davide Italiano for their help with this import, and thanks to Antoine Brodin for performing a ports exp-run.

After the ports exp-run, a small number of ports turned out to have problems, and for almost all of these, PRs with fixes or workarounds were filed. While most of these PRs have been processed and closed, there are still a few left that need attention, from either the maintainer(s) or other volunteers.

Andrew Turner is working on bringing up the arm64 architecture, which is now fully supported in clang and llvm. This will be a very interesting new area for solving challenging problems.

There are still issues with the powerpc and sparc64 architectures, and any help in these areas is very much appreciated.

 The &os; Foundation Deb Goodkin deb@FreeBSDFoundation.org Foundation website &os; Journal BSDNow PC-BSD Tour BSDNow "From the Foundation"

The Foundation turned 15 on March 15th! We kicked off our anniversary celebration by launching a spring fundraising campaign, to bring in 500 new community investors. In conjunction with our anniversary, BSDNow interviewed Justin Gibbs about our history and plans for the future as part of the PC-BSD tour. BSDNow also interviewed Ed Maste about &os; projects and processes in a "From the Foundation" episode.

We were a Platinum Sponsor of AsiaBSDCon and had five team members attend the conference. Kirk McKusick taught a two-day &os; kernel tutorial and gave a talk on Journaled Soft Updates and George Neville-Neil gave a talk on network performance in &os;; George also taught a two day tutorial (A Look Inside FreeBSD with DTrace). This is from ongoing work with Robert Watson in support of both academic and practitioner educational material for &os;. Dru gave a talk on Advanced OpenSource Storage with FreeNAS 9.3, and Ed Maste gave a talk on the LLDB Debugger in FreeBSD.

We became a Platinum Sponsor for BSDCan, and have approved six travel grants to &os; contributors. We also sponsored Michael Dexter to attend SCALE so he could give a talk on virtualization.

In addition to the above conferences, we helped promote &os; at the following conferences:

We received and published &os; testimonials from Xinuos, Netgate, and Tarsnap.

We launched the "From the Trenches" series to provide stories from &os; contributors on what they are doing with &os;. Glen Barber wrote an article called ZFS and How to Make a Foot Cannon. Glen also investigated a deadlock issue when rebooting after upgrades (PR 195458), and he released weekly 11-CURRENT and 10-STABLE snapshot builds.

The &os; Journal now has over 8300 subscribers and has a 98% renewal rate. We are now publishing a few free &os; Journal articles. We also created landing pages for each Journal issue for easier promotion.

We started work on the Ottawa Vendor and Developer Summits and another one that has not yet been officially announced on the East Coast in the fall.

Our development staff and project grant recipients were responsible for a large number of feature improvements and bug fixes over this past quarter. We have eight individual reports in this quarterly update for Foundation-sponsored projects that demonstrate a number of different ways the Foundation supports the &os; project.

One project is the subject of a research master's project at Swinburne University in Melbourne: the Multipath TCP (MPTCP) implementation for &os;. The PCIe hot plug project is an individual project grant. The FreeBSD/arm64 project represents a collaborative development effort, where the Foundation facilitates a broader project with multiple participants.

There are also a number of projects undertaken directly by Foundation staff. In this quarterly report we have several reports in this category: Secure Boot, the autofs-based automount daemon, dynamically loadable libthr, Intel DMA remapping, migration to the ELF Tool Chain project tools.

Additionally, one of the benefits of having long-term permanent staff is the ability to continue to maintain projects and contribute improvements beyond a fixed timeline. Over the last quarter Foundation staff contributed improvements to the UEFI boot process, vt(4) system console, in-kernel iSCSI stack, the virtual memory subsystem, and many others.

 Adding PCIe Hot-plug Support John-Mark Gurney jmg@FreeBSD.org PCIe Hot-plug Perforce Branch

PCI Express (PCIe) hot-plug is used on both laptops and servers to allow peripheral devices to be added or removed while the system is running. Laptops commonly include hot-pluggable PCIe as either an ExpressCard slot or a Thunderbolt interface. ExpressCard has built-in USB support that is already supported by &os;, but ExpressCard PCIe devices like Gigabit Ethernet adapters and eSATA cards are only supported when they are present at boot, and removal may cause &os; to crash.

The goal of this project is to allow these devices to be inserted and removed while &os; is running. The work will provide the basic infrastructure to support adding and removing devices, though it is expected that additional work will be needed to update individual drivers to support hot-plug.

Current testing is focused on getting a simple UART device functional. Basic hot swap is functional.

The &os; Foundation

Get suspend/resume functional by saving/restoring the necessary registers.

Make sure that upon suspend, devices are removed so that if they are replaced while the machine is suspended, the new devices will be detected.

Improve how state transitions are handled, possibly by using a proper state machine.

 The Graphics stack on FreeBSD &os; Graphics team freebsd-x11@FreeBSD.org Graphics stack roadmap and supported hardware matrix Graphics stack team blog Ports development tree on GitHub

In the official Ports tree, the Mesa ports (libglapi, libGL, libEGL, libglesv2, gbm, dri) are kept close to the latest Mesa 10.4.x release.

In the development tree (see the GitHub link), the update to Mesa 10.5 came along with several improvements and cleanup to the ports themselves. Now, all ports share the same configure flags and build dependencies. As Mesa is built from scratch for each port, this ensures that all libraries and drivers are consistent with each other. This fixes at least two problems:

The downside of this unification is that all ports will depend on LLVM. This work is happening in the mesa-10.5 branch.

Progress has been made on OpenCL, thanks to help from Johannes Dieterich. Clover (Mesa's implementation) and Beignet (Intel's implementation) were added as ports to the development tree. They were tested successfully on Radeon and Intel GPUs, but see the wiki for an up-to-date status. Initially developed in the opencl branch, everything has now been merged into the mesa-10.5 branch. This cannot go into the official Ports tree yet because it requires the unification explained above.

A new port, drm-kmod was added to the official Ports tree. It provides updated drm2, i915kms and radeonkms kernel modules for FreeBSD 9.3-RELEASE and 9.3-STABLE. The only difference from the vanilla modules is the addition of hardware context support to the i915 driver. The xf86-video-radeon and xf86-video-intel drivers were patched to use the drm-kmod port on these versions of FreeBSD. This will allow us to remove the duality of the Mesa ports (libGL/libEGL/dri) and only support one version (as is already the case in the mesa-10.5 branch where Mesa 9.1.7 is gone). There is no ETA yet for when this last part will happen.

In the development Ports tree, the xserver-next branch was updated from xorg-server 1.16 to be tracking 1.17. Again, this depends on the previous step: the removal of Mesa 9.1.7.

Work is finishing up on an update of miscellaneous X.Org components. Apart from updates to several X.Org ports, this update also removes the use of .la files from the X.Org libraries that still have them. Also, the xf86-video-intel driver will receive patches to allow it to compile against a newer xorg-server than 1.14. Most of the X.Org component updates were submitted by Matthew Rezny.

The location where fonts get installed was overhauled and the way to handle fonts from the plist got simplified. Now all fonts are installed in /usr/local/share/fonts as required by the XDG rules. Furthermore, making a port for fonts should be easier: more aspects, such as calling fc-cache(1), are handled by the Ports framework. Therefore, the font ports' consistency was greatly improved.

In the kernel, the DRM device-independent code was updated to match Linux 3.8. A merge to 10-STABLE is pending. The i915kms kernel driver received an update too, which is already merged to 10-STABLE.

Having both updates in place enables work on a second update of the i915 driver: this time it will be synchronized with Linux 3.8, like the rest of the DRM subsystem, and bring Haswell support. This was started recently. Our hope is that it will be ready in time for FreeBSD 10.2-RELEASE.

During Q2, we are going to work with the GNOME team on porting libinput and testing Wayland. Currently we know that GTK+3 and GNOME 3 have full support for Wayland. We also need to test Xwayland from xorg-server 1.16+ to support X applications on Wayland desktops. If you know of more software that uses Wayland, we would like to hear about them. At this point there are no plans to port the Weston reference implementation of a Wayland compositor.

See the "Graphics" wiki page for up-to-date information.

 Wine/FreeBSD Gerald Pfeifer gerald@FreeBSD.org David Naylor dbn@FreeBSD.org Wine wiki Wine on amd64 wiki Wine homepage

This quarter has seen five updates to the wine-devel port that closely tracks upstream development, as well as updates to helper ports (wine-gecko-devel and wine-mono-devel):

A major development has been the introduction of Wine64 (i.e., the ability to run 64-bit Windows applications). This is currently available through the wine-devel port. At this stage it is currently mutually exclusive with the i386-wine-devel port, however we have plans to intregate these ports to offer a full Wine experience on amd64. The i386-wine-devel port has packages built for amd64 for &os; 8.4, 9.1+, 10.1+ and CURRENT.

Accomplishments include:

We would like to thank all volunteers who contributed feedback and patches.

Future development on Wine will focus on:

Maintaining and improving Wine is a major undertaking that directly impacts end-users on &os; (including many gamers). If you are interested in helping, please contact us. We will happily accept patches, suggest areas of focus or have a chat.

&os;/amd64 integration (see the i386-Wine wiki).

Porting WoW64.

 &os; on newer ARM boards John Wehle john@feith.com Ganbold Tsagaankhuu ganbold@FreeBSD.org &os; on Odroid-C1

We made the changes necessary to support various Amlogic SoC devices, specifically aml8726-m6 and aml8726-m8b SoC-based devices. The aml8726-m6 SoC is used in devices such as the Visson ATV-102, and the Hardkernel ODROID-C1 board uses the aml8726-m8b SoC. The following support is included:

Get the DWC driver working.

 FreeBSD Python Ports &os; Python Team python@FreeBSD.org The &os; Python Team Page IRC channel

The &os; Python team continued to improve the overall experience with Python-based software on &os;. A lot of previously deprecated code and option knobs were removed to improve the maintainability of the Python Ports infrastructure.

The CPython interpreters were updated to version 2.7.9 and 3.4.3 and Twisted was updated to version 15.0.0.

Retire the Python 3-specific port duplicates.

More tasks can be found on the team's wiki page (see the links).

To get involved, interested people can say hello on IRC in #freebsd-python on freenode and let us know their areas of interest!

 KDE on &os; KDE on &os; team kde@FreeBSD.org

The KDE on &os; team focuses on packaging and making sure that the experience of KDE and Qt on &os; is as good as possible.

First of all, we would like to welcome Tobias Berner to the ranks of the area51 committers. He has been regularly mentioned in our recent status reports, and has finally received committer privileges to our experimental repository. Becoming an area51 committer is usually the first step towards becoming a kde@ ports committer. We hope that Tobias can fix and update our ports more easily, and start committing his KDE Frameworks 5 ports to area51.

Additionally, this quarter Qt 5.4.1 was committed to the ports tree. This marks the first time ever since Qt 5 was released that we have the latest upstream stable release in our ports tree! This was made possible by all the work we had to put into cleaning up the Qt 5 ports infrastructure for the 5.3 update, mentioned in our previous status report.

Last but not least, Alonso Schaich finally landed an update to our KDE4 ports that had been in our experimental repository for a while, bringing them to the latest 4.14 release, 4.14.3.

Overall, we have updated the following ports in this quarter:

Put more effort into Qt5-related ports: KDE Frameworks 5 (currently worked on by Tobias Berner) and PyQt 5.

 FreeBSD Ada Ports John Marino marino@FreeBSD.org

There are 51 Ada-related ports currently, but two of them are being retired: the GCC 4.7-based lang/gcc47-aux and the BSD->android cross-compiler for ARMv5 (lang/gnatdroid-armv5). The former has no advantage over the newer GCC 4.9-based lang/gcc-aux, and the latter has not built for over a year. Android enthusiasts can still use the the ARMv7 cross-compiler (lang/gnatdroid-armv7).

A new port is lang/gcc5-aux, which includes GNAT from the upcoming release of gcc5. This compiler already builds all Ada ports except gtkada3 (which blocks the devel/gps — the GNAT Programming Studio), and gtkada3 should be fixed soon. When GCC5 is released, the Ada framework will switch to using gcc5-aux as the default compiler. For those that cannot wait, it is possible to use it now by putting ADA_DEFAULT=5 in /etc/make.conf, but this requires rebuilding all Ada ports from source.

It is a near-term objective to bring the Ada-based GDHL (VHDL simulator) to ports. The upcoming release 0.32 will be based on GCC 4.9 and the port will be based on this release.

 GNOME on &os; &os; GNOME Team freebsd-gnome@freebsd.org GNOME development repo

The &os; GNOME Team maintains the GNOME, MATE, and CINNAMON desktop environments and graphical user interfaces for &os;. GNOME 3 is part of the GNU Project. MATE is a fork of the GNOME 2 desktop. CINNAMON is a desktop environment using GNOME 3 technologies but with a GNOME 2 look and feel.

At the end of this quarter we updated GNOME and CINNAMON to the latest versions on their branches, 3.14 and 2.4, respectively.

GNOME 3.16 was released February 25th; we ported it to &os;. There are still some showstopper problems that showed up. During testing of the current versions of the 3.16 ports a bug in pkg was uncovered in the multiple repository support, and swiftly fixed in pkg 1.4.99.15.

For the GNOME 3.18 cycle we going to work closely with the x11 team on porting libinput and testing Wayland. When that is done we need to see if we want to enable Wayland for our stable releases and we probably need XWayland from xorg-server 1.16+ to support X applications. The estimate is that Wayland arriving in ports will have to wait until 8.4-Release is EOL.

The GNOME website is stale. Work is underway, although slowly, on the development section. We could use some help here.

MATE 1.10 porting is under way; the latest 1.9 releases are available in the mate-1.10 branch.

 Nanosecond file timestamps Jilles Tjoelker jilles@FreeBSD.org Sergey Kandaurov pluknet@FreeBSD.org

Two new system calls, futimens() and utimensat(), were added, making it possible to set file timestamps with nanosecond accuracy. Various utilities like cp, mv and touch were changed to use the new calls to preserve and set timestamps with full precision.

The stat() and related system calls have returned file timestamps with nanosecond accuracy for a long time, but there was no way to set a timestamp more accurately than microseconds.

With these changes, it will be possible to use more accurate timestamps (sysctl vfs.timestamp_precision=3) without anomalies such as a copy of a file (from cp -p) appearing older than the original. This is particularly useful for NFS servers, which use file timestamps for cache invalidation.

Where possible, fix code that still sets inaccurate timestamps on files, typically by calling futimes(), futimesat(), lutimes(), utime() or utimes() with a non-null times pointer. There may be a reason for this such as a limited network protocol or file format, but there is some code left that can be fixed.

 CheriBSD Robert Watson rwatson@FreeBSD.org Brooks Davis brooks@FreeBSD.org David Chisnall theraven@FreeBSD.org Ruslan Bukin br@FreeBSD.org

CheriBSD is a fork of &os; to support the CHERI research CPU. We have extended the kernel to provide support for CHERI memory capabilities as well as modifying applications and libraries including tcpdump, libmagic, and libz to take advantage of these capabilities for improved memory safety and compartmentalization. We have also developed custom demo applications and deployment infrastructure for our table demo platform.

As this goes to press, we are finalizing our first open source release of the CHERI CPU which will be available from the CHERI CPU website (in the links).

We have been merging support for the BERI CPU platform to &os; since 2012 and continue to do so as new features are developed. Most recently Ruslan has added support for the Terasis SoCkit board which combines an ARM processor with an FPGA capable of running BERI (and soon CHERI) in a single package.

DARPA/AFRL Mellanox iSCSI Extensions for RDMA (iSER) Support Max Gurtovoy maxg@mellanox.com Sagi Grimberg sagig@mellanox.com

Building on the new in-kernel iSCSI initiator stack released in &os; 10.0, and the recently added iSCSI offload interface, Mellanox Technologies has begun developing iSCSI extensions for RDMA (iSER) initiator support to enable efficient data movement using the hardware offload capabilities of Mellanox's 10, 40, 56, and 100 gigabit IB/Ethernet adapters.

Remote Direct Memory Access (RDMA) has been shown to have a great value for storage applications. RDMA infrastructure provides benefits such as zero-copy, CPU offload, reliable transport, fabric consolidation and many more. The iSER protocol eliminates some of the bottlenecks in the traditional iSCSI/TCP stack, provides low latency and high throughput, and is well suited for latency-aware workloads.

This work includes a new ICL module that implements the iSER initiator. The iSCSI stack is slightly modified to support some extra features such as asynchronous IO completions, unmapped data buffers, and data-transfer offloads. The user will be able to choose iSER as the iSCSI transport with iscsictl.

The project is in its initial implementation phase. The code will be released under the BSD license and is expected to be completed later this year.

Mellanox Technologies FreeBSD Bugmeister &os; Bugmeister bugmeister@FreeBSD.org

Bugzilla replaced GNATS in June 2014 as the bug management tool of choice for &os;, granting GNATS its well-deserved retirement after more than 20 years of operation. The following months were rough for Bugzilla: a lot of functionality was still missing and several uncertainties caused users and committers to adapt only slowly to the new system.

Over the last six months, a lot of missing features were brought into place to allow users and committers to focus on getting bugs solved. Categories, the status model and many workflow-related knobs were continously reworked and improved to provide the necessary information without getting in the way.

An auto-assigner for ports issues was implemented, resembling what GNATS' successfully did in the past. A dashboard page within Bugzilla provides users and committers with common queries and overall statistics; many other smaller tweaks, configurations, and extensions were implemented to improve the usability of the system.

An improved reporting system is currently being implemented to provide graphs and statistics for users and committers. Handling MFCs and a better feedback mechanism for requests (flags in Bugzilla) will be the next things to do.

Bugmeister is also working closely with the &os; GitHub team to establish a workflow between GitHub's issue tracker and our Bugzilla system. The technical solution already exists as a proof of concept, but its usage in production will have to wait until Bugzilla 5.0 has been adopted.

Create a solid charting extension for &os; Bugzilla.

Improve MFC handling.

Do you feel that something important is missing? Let us know!

 Modern x86 platform support and VT-d Konstantin Belousov kib@FreeBSD.org

Modern x86 platforms include a number of architectural enhancements. Work is ongoing to support these features in &os;.

Starting with SandyBridge CPUs, Intel introduced an enchanced local interrupt controller (APIC) mode, called x2APIC. Instead of using a mapped page, registers are now accessed using special Model-Specific Registers (MSR) read and write instructions. This is intended to support virtualization. The access overhead is also reduced by not requiring serialization, and by simplification of Inter-Process Interrups (IPI) generation. The main commit introducing the feature was r278473, with fixes following on.

End Of Interrupt (EOI) suppression is a mode of EOI delivery to Input/Output Interrupt Controllers (IO-APICs) where the EOI message for a level-triggered interrupt is not broadcast by an EOI write to the local APIC, but instead an explicit EOI command is sent to the source IO-APIC. The optimization reduces the number of APIC messages that must be broadcast. It should be used on all modern Intel systems. Support for EOI suppression was committed in r279319.

VT-d Interrupt Remapping (IR) is provided by hardware with the VT-d feature. It translates interrupt messages on the way from the root complex to the north bridge and allows control of interrupt delivery without reprogramming MSI/MSI-X registers or IO-APICs. The original intent was to allow hypervisors to safely delegate interrupt programming for devices owned by guests to the guest OS. But IR is also needed to avoid some limitations in IO-APICs and to make interrupt rebalancing atomic and transparent. Support has been committed as r280260.

Both x2APIC mode and IR are required to send IPIs and device interrupts to processors with LAPIC ID greater then 254. It is believed that the only missing platform code to handle big machines is parsing the "Processor Local x2APIC Structure" and "Local x2APIC NMI Structure" from the ACPI Multiple APIC Description Table (MADT), which report LAPIC IDs > 255, and handling boot on such systems with the x2APIC mode enabled by firmware. The work to complete that is expected to be relatively trivial, and can be done with access to a real high-core-count machine. But an audit of the common machine-independent code must be finished to ensure that large CPU IDs are handled correctly, before such support can safely be enabled..

Additional work remains in progress: split domains and contexts for DMA Remapper Unit (DMAR) driver. Right now, the DMAR driver is only used to implement busdma(9), which is done by assigning a dedicated domain to each translation context. Some devices could issue PCIe Transaction Laeyer Packets (TLPs) with several originators IDs, e.g., PCIe/PCI bridges, or phantom functions of PCIe devices, or such TLPs could occur just due to hardware bugs. To handle them, a single domain (which shares the translation page tables) must handle several contexts.

Splitting domains and contexts is also required for the DMAR driver to start handling PCI pass-through in bhyve, instead of the less complete implementation which is currently provided by bhyve itself. All PCIe devices passed to the guest must share a domain. The splitting patch is written and is being tested, and external interfaces to manage domains are being formed.

Stability work for the VT-d code is ongoing. In particular, nvme(4) and ixgbe(4)'s use of busdma interfaces was debugged and improved, and tested on a very large-memory machine.

The &os; Foundation libthr improvements Konstantin Belousov kib@FreeBSD.org

Historically, dynamic loading of the libthr.so thread library into a single-threaded process did not work in &os;. The longstanding recommendation to work-around the problem has been to always link the main binary with -lpthread if there was any chance of a need for threading functionality. This project converted libthr.so into a plugin for libc, which fixed the known issues preventing dynaic loading of libthr.so.

After the fix, linking the main binary with -lpthread is no longer requred, but is not harmful. I recommend thoroughly testing before removing libpthread from the libraries list in favor of dynamic loading, though. Note that potential problems will be subtle and their user-visible manifestations in the affected program even more surprising.

The following issues were present in the old version of libthr with respect to dynamic loading, but are fixed as a result of this work:

The main change was committed as r276630 to HEAD, with many follow ups. It was merged to stable/10 in r277317.

The &os; Foundation Nested Kernel Nathan Dautenhahn dautenh1@illinois.edu Theodoros Kasampalis kasampa2@illinois.edu Will Dietz wdietz2@illinois.edu Home page for the project that includes links to papers and build instructions. Conference publication detailing the problem, design, implementation, and evaluation of our prototype. Presentation on the nested kernel HardenedBSD branch of the nested kernel being refactored.

This work on a nested kernel architecture is part of Nathan's doctoral thesis work at the University of Illinois at Urbana-Champaign. It attempts to improve upon the traditional monolithic operating sytsem kernel, where a single exploit anywhere in the kernel grants the attacker full superuser privileges. The nested kernel operating system architecture addresses this problem by "nesting" a small, isolated kernel within a traditional monolithic kernel. This "nested kernel" interposes on all updates to virtual memory translations to assert protections on physical memory, thus significantly reducing the trusted computing base for memory access control enforcement. We incorporated the nested kernel architecture into &os; on x86-64 hardware by write-protecting Memory-Management Unit (MMU) translations and de-privileging the untrusted part of the kernel, thereby enabling the entire operating system, trusted and untrusted components alike, to operate at the highest hardware privilege level. Our implementation inherently enforces kernel code integrity while still allowing dynamically loaded kernel modules, thus defending against code injection attacks. We also demonstrate, by introducing write-mediation and write-logging services, that the nested kernel architecture allows kernel developers to isolate memory in ways not possible in monolithic kernels. The performance of the nested kernel prototype shows modest overheads: less than 1% average for Apache, 3.7% average for sshd, and 2.7% average for kernel compilation. Overall, our results and experience show that the nested kernel design can be retrofitted onto existing monolithic kernels, providing defense in depth.

The basic idea is that the nested kernel initializes the system so that all page tables are mapped as read-only. Then all MMU-modifying operations are removed from the untrusted portion of the kernel; runtime code integrity is enforced by write-protecting all code pages, marking all non-code pages as non-executable (NX-bit), and preventing execution of privileged MMU operations located in userspace mappings (Supervisor Mode Execution Prevention, SMEP). Because the nested kernel has control of the page tables it can enforce these integrity properties leading to virtualization of the MMU.

The links include a recent conference publication that details the design, implementation, and evaluation of our prototype nested kernel architecture on top of &os; 9.0. We are also bringing up a site with instructions on how to get the source and build the project. There is also a link to a presentation on the nested kernel.

We are very interested in feedback on the design of the nested kernel, and having discussions about how it might get upstreamed. This is our first time contributing to an open source project, so even simple advice is likely to be useful.

We are also hoping to gain additional contributors and interest in the project! The nested kernel has the potential to enhance commodity operating system design, and &os; is a major operating system in use today which has high impact. The source code of our research prototype as evaluated for the paper are in the process of being made available — the website and code are almost ready but may take another week to complete. However, the implementation is merely a research prototype and requires significant effort to make production-ready (see the list of tasks). Some of this work is underway during refactoring for an implementation in the HardenedBSD project, which is a much cleaner version of the core system and is integrated into the &os; build system, but is only about 50% completed.

Finally, we have developed an interface to write-protect data structures in the kernel and are soliciting ideas for uses of this service. Section 2.4 in the paper details the interface, and section 4 presents some simple uses of the nested kernel services. We are interested in ways that the nested kernel could be used to protect critical kernel data structures from malware or even just buggy code.

University of Illinois at Urbana-Champaign ONR via grant number N00014-12-1-0552

Finish implementing core mechanisms: verify DMAP is properly protected and that we are not using superpages (I think we have this completed but need to fully verify), full NX support for all non-kernel code pages (we might need to specially consider the stack if it is used to execute code), protect IDT and SMM, and add IOMMU protections. We also need to do some optimizations where we batch calls into the nested kernel on process creation (FORK) and mmap operations. The motivation for these implementation directives can be reviewed in the paper.

Implement SMP functionality and evaluate performance.

Port and refactor for a newer version of &os;. The current implementation is a research prototype and requires some refactoring to make it clean and consistent, as well as make it relevant to modern versions of &os;.

The nested kernel isolation depends upon certain hardware instructions to be completely removed from a subset of the kernel. Therefore, we need to utilize automated linker/loader techniques to identify and remove privileged MMU operations from untrusted kernel components to make it maintainable in practice.

Detailed review on the design and implementation with particular focus on a plan for upstreaming.

 + + + Multipath TCP for &os; + + + + + Nigel + Williams + + njwilliams@swin.edu.au + + + + + + + + +

Multipath TCP (MPTCP) is an extension to TCP that allows + for the use of multiple network interfaces on a standard TCP + session. The addition of new addresses and scheduling of data + across these occurs transparently from the perspective of the + TCP application.

+ +

The goal of this project is to deliver an MPTCP + kernel patch that interoperates with the reference MPTCP + implementation, along with additional enhancements to aid + network research.

+ +

After a major re-design of the earlier prototype + implementation, the patch is again able to establish and carry + out multi-path connections that incorporate multiple addresses. + Improvements have also been made to path management and to code + handling the addition of subflows to a connection.

+ +

I have most recently added data-level re-transmission + support and am in the process of testing this. I will soon be + in a position to start more extensive testing of the patch in + different multi-path scenarios, with plans for a public release + of v0.5 in May.

+ + + The &os; Foundation + + + +

Testing of data-level re-transmission.

+ + + +

Basic support for per-subflow congestion control + algorithm selection.

+ + + +

Testing and release of v0.5 patch.

+ + +