Index: head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml (revision 46984) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml (revision 46985) @@ -1,1475 +1,1529 @@ April-June 2015
Introduction

This is a draft of the April–June 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 April and June 2015. This is the second of four reports planned for 2015.

Another productive quarter for the &os; project and community has passed. BSDCan was held in Ottawa in June, and both it and the preceding Developer Summit allowed developers to plan for the future and discover what others have already accomplished.

Thanks to all the reporters for the excellent work!

The deadline for submissions covering the period from July to September 2015 is October 1, 2015.

?>
team &os; Team Reports proj Projects kern Kernel arch Architectures bin Userland Programs ports Ports doc Documentation misc Miscellaneous New Documentation Committers &os; Documentation Engineering Team doceng@FreeBSD.org &os; Porter's Handbook &os; Web Site &os; Foundation Web Site

Two new documentation committers were added to the team in the second quarter of 2015.

Mathieu Arnold is a member of the &os; Ports Management Team. Over the past year, he has worked on many large and complex updates to keep the Porter's Handbook current, and continues to update this important document.

Anne Dickison is Marketing Director for the &os; Foundation. She will focus on updating and improving the &os; main web site.

We welcome both new committers and look forward to their additional contributions!

 Documentation Working Group at BSDCan &os; Documentation Team freebsd-doc@FreeBSD.org BSDCan reStructured Text Markdown AsciiDoc &os; Wiki &os; Web Site Annotator Annotator Backend Stores

During the Developer Summit held in the two days before BSDCan, a documentation working group meeting was held. We discussed some of the biggest opportunities available to the documentation team.

Modernizing our translation system was, again, a major topic. Making it easier for translators to do their work is vitally important. Translations make &os; much more accessible for non-English speakers, and those people and the translators themselves often become valuable technical contributors in other areas. Progress was made in this area, and we hope to have more news soon.

Methods of making it easier for people to contribute to documentation was another major topic. At present, we use DocBook XML for articles and books, and mdoc(7) for man pages. These markup languages are not very welcoming for new users. There are simpler documentation markup languages like RST, Markdown, and AsciiDoc that take less time to learn and use. In fact, these markup systems are all similar to each other. These systems tend to be more oriented towards visual appearance rather than the semantic markup of our present systems, there might be ways to work around that.

Following the theme of making contributing easier, we also discussed giving easier access so users can make additions to the &os; Wiki. Like any other useful web resource, it was horribly abused by spammers and access was limited to prevent that abuse. It is tricky to allow submissions yet keep the quality of submitted information usefully high.

Due to the markup systems used, it is difficult to review documents for the quality of their information. Annotator is a Javascript system that allows adding notes to an existing web page. This would allow us to hold content-only reviews of documentation web pages. Reviewers would not see markup, so they could concentrate only on whether the information was accurate and complete. To use this as desired, we need some help with ports and testing.

Complete a port for the backend storage component of Annotator. Preferably this would be the lowest overhead and most open-licensed version available. Assistance from those familiar with Python and Javascript web development is welcome.

 &os; Support in <tt>pkgsrc</tt> Sevan Janiyan venture37@geeklan.co.uk pkgsrc home page BulkTracker - Track bulk build status My blog posts on pkgsrc

pkgsrc is a fork of &os; ports from the NetBSD project with a focus on portability and multi platform support. At present, pkgsrc supports building packages on 23 different platforms from a single tree, including &os;

While pkgsrc is not a replacement for ports in most use cases, it holds a unique position in mixed platform environments where software ideally needs to be the same version across the board and should built in a consistent manner, saving the user from having to resort to manually building programs or re-implementing a mechanism to do so.

With the recent 2015Q2 release earlier this month, it is now possible to generate over 14000 packages on FreeBSD 10.1-RELEASE (up from 12800 last quarter).

Work is in progress to add pkgng support to pkgsrc.

Improve platform support to skip libusb on &os; where libusb is bundled in base. This is causing the biggest breakage at the moment.

Expand the effort to -STABLE and -CURRENT branches and, if possible, architectures other than AMD64. Shell access welcome (without privilege is sufficient).

 ZFS Support for UEFI Boot/Loader Eric McCorkle emc2@metricspace.net

UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem. The patch currently works with buildworld, and successfully boots on a test machine with a ZFS partition. In addition, the ZFS-enabled loader.efi can be treated as a chainloader using ZFS-enabled GRUB.

The work on boot1.efi also reorganizes the code somewhat, splitting out the filesystem-specific parts into a modular framework.

More testing needed for the following uses: ZFS with GRUB+loader.efi, ZFS with boot1+loader.efi, UFS with boot1+loader.efi (test modularization of boot1.efi)

Have boot1.efi check partition type GUIDs before probing for filesystems.

Get patch accepted upstream and committed.

 Xfce on FreeBSD &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.

During this quarter, the team has kept these applications up-to-date:

Mathieu Arnold (mat@) committed PR197878, updating the Xfce section in the Porter's Handbook.

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

Create documentation about usage of sysutils/xfce4-power-manager (it needs some love, PR199166).

Some hidden features were introduced in the 1.5.1 release, and as we also support ConsoleKit2 (fork of sysutils/consolekit), help for users is required.

 FreeBSD Mastery: ZFS Now Available Michael Lucas mwlucas@michaelwlucas.com

The first ZFS book is now available at your favorite bookstore. Find a whole bunch of links at zfsbook.com.

Work is proceeding apace on "FreeBSD Mastery: Advanced ZFS" and "FreeBSD Mastery: Specialty Filesystems." Lucas hopes to have FMAZ complete and available before the next status report.

 The FreeBSD German Documentation Project Björn Heidotting bhd@FreeBSD.org Johann Kois jkois@FreeBSD.org Benedict Reuschling bcr@FreeBSD.org Main German Documentation Project page How you can help with german translations

The &os; German Documentation project maintains the German translations of &os;'s documents such as the Handbook and the website.

In the second quarter of 2015, we managed to catch up with the translation work of the Handbook. Two chapters are now back in sync with their English reference chapters: filesystems and ZFS. The former was mainly done by Björn Heidotting as part of his mentee process. The latter was done by Benedict Reuschling, which valuable corrections by Björn.

Additionally, we updated many of our translation markers from pre-SVN times. This will help us get an overview of the outstanding work in each chapter. We are working on integrating this into our website using a script, so people can see which chapters need the most work or are most up-to-date.

Johann made efforts to update the &os; Documentation Project Primer as well, so that translators willing to help us can read the information in German. He also made efforts to revive the Documentation Project website, which was previously hosted elsewhere, but disappeared. Now, it is tied into the German FreeBSD.org website again and has the same look and feel.

Occasionally, people contact us and offer their help with the translation effort. We are happy to help newcomers get to know everything about the translation process and look forward to more contributions. Even small updates make a big difference and if you are considering to help, please contact us.

Continue translating the Handbook and website into German.

Integrate a script that shows outstanding work into the German documentation webpages.

 Multiqueue Testing Tiwei Bie btw@FreeBSD.org Hiren Panchasara hiren@FreeBSD.org

The aim of this project is to design and implement a infrastructure to validate that a number of the network stack's multiqueue behaviours are as expected.

It mainly consists of extending tap(4) to provide the same RSS behaviours with the hardware multiqueue network cards, developing simple test applications using multiqueue tap(4) and socket(2), adding hooks in each layer of the network stack to collect the per-ring per-cpu per-layer statistics, and extending netstat(1) to report these statistics.

At present, most parts of this project have been implemented. The focus is on the code review, and API/KPI freeze.

Google Summer Of Code 2015 &os; Release Engineering Team &os; Release Engineering Team re@FreeBSD.org &os; 10.2-RELEASE schedule &os; development snapshots &os; development snapshots announcements list

The &os; Release Engineering Team is responsible for setting and publishing release schedules for official project releases of &os;, announcing code freezes and maintaining the respective branches, among other things.

The &os; 10.2-RELEASE cycle began in mid-June, with the final release expected to be available in late August, and as this quarterly status update shows, &os; 10.2-RELEASE is going to be a very exciting release.

The &os; Release Engineering Team has been extremely busy this quarter, with much of the focus targeted at adding support for additional hardware and integration with third-party hosting providers (aka "cloud" hosting).

In follow-up with the work done by &a.andrew; to port &os; to the ARM64 (aarch64) architecture, the Release Engineering build tools were updated to produce &os;/aarch64 memory stick images and virtual machine images for use with Qemu (emulators/qemu-devel). At present, the Qemu virtual machine images require an external EFI file to boot. Details on how to boot &os;/aarch64 virtual machine images are available in the &os; development snapshot announcement email archives linked below.

Last quarter, several parts of the build tools were rewritten to allow greater extensibility and granularity, which has simplified the code required for new virtual machine images.

In collaboration with several developers, the Release Engineering build tools were updated to provide new support for several hosting providers, as well as provide mechanisms to automatically upload (and publish, where possible) &os; virtual machine images.

This quarter, in addition to the existing support for the Microsoft Azure platform, the build tools also natively support:

The &os; Release Engineering Team would like to thank these developers for all of the work that went into making this possible, and would like to especially thank &a.marcel; for all of his work on the mkimg(1) utility, especially for adding support for the various file formats requested.

In addition to the enhancements to the virtual machine build tools, a significant amount of work went into refactoring the build code used to produce &os;/arm images.

With much of the logic resembling how the Crochet utility (written by &a.kientzle;) works, and a significant amount of work, input, and advice from &a.ian;, &a.imp;, &a.andrew;, &a.loos;, and a large number of contributors on the freebsd-arm@FreeBSD.org mailing list, the &os; Release Engineering tools now natively support producing &os;/arm images without external build tools.

At present, the build tools are support building &os;/arm images for:

The &os; Release Engineering Team would like to thank each of these people for their support and input, and would like to especially thank &a.kientzle; for his work on Crochet. Without it, we might not have been able to produce images of the various boards that we are able to now.

For more information on what else has changed in &os; since 10.1-RELEASE, see the &os; 10.1-STABLE release notes (which will become the release notes for 10.2-RELEASE).

Additionally, &a.gjb; would like to thank Jim Thompson for providing a BeagleBone Black board (replacing one that no longer worked), and Benjamin Perrault for providing a PandaBoard ES, both of which are used for locally testing the images produced by the build tools.

Last, and certainly not least, &a.gjb; would also like to thank the &os; Foundation for their support, and for providing the resources (time and hardware) required to make all of the items mentioned in this status report possible.

The &os; Foundation BSDCan 2015 Dan Langille dvl@FreeBSD.org

BSDCan, a conference for people working on and with 4.4BSD-based operating systems and related projects, was held in Ottawa, Ontario on June 12 and 13. A two-day &os; developer summit event preceded it on June 10 and 11.

This was the largest BSDCan ever, with over 280 attendees, up by more than 40 people over the 2014 event. There were a record number of speakers and talks. An additional room and "track" was added to provide even more choices for concurrent talks on both days of the conference. Social media response to the whole conference has been very positive.

The keynote talk by Stephen Bourne was very popular. So popular, in fact, that the main conference room could not hold all the attendees. An overflow room with live video was set up to hold the extra people. The video of the presentation has had over 6300 views in the first twelve days.

Andrew Tanenbaum's talk on reimplementing NetBSD using a MicroKernel was so well-attended it was standing room only.

There were many other excellent talks, and we recommend browsing through the playlist in the links above.

Activity was not limited to the talks. Each night, the "Hacker Lounge" was used by developers to cooperate and interact on projects. Embedded projects were popular this year, as FreeBSD was installed directly on wireless routers.

The very successful and well-attended closing event, held at the Lowerton Brewery, provided an elegant closure to the whole conference.

We would like to thank everyone who made BSDCan 2015 such a success, and look forward to next year!

 Adding PCIe Hot-plug Support John-Mark Gurney jmg@FreeBSD.org PCIe Hot-plug P4 Branch Commit adding bridge save/restore. Github branch with patches

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 a hot-pluggable PCIe as either an ExpressCard slot or 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.

A set of the patches is now available on github.com.

The FreeBSD Foundation

Get suspend/resume functional by save/restoring necessary registers. This should be addressed by r281874.

Make sure that upon suspend, devices are removed so we are not fooled if they are replaced while the machine is suspended.

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

 Leap Seconds Article Warren Block wblock@@FreeBSD.org

As the leap second scheduled for the end of June approached, Bartek Rutkowski and others raised questions about how &os; handled leap seconds. Leap seconds have caused serious problems for other operating systems in the last few years, and there was understandable concern.

It was reasonably pointed out that &os; had encountered leap seconds before, and would be fine this time also. Still, the absence of reported problems is not really a substitute for a description of what to expect and how to know if a system is prepared.

To address concerns and also provide a resource for future leap seconds, several experts were harrassed relentlessly, with the results compiled into a short article. Beyond merely allaying fears about what might happen, this article received positive responses on the web for how it demonstrated &os;'s maturity and preparedness.

Great thanks for their patience and expertise are owed to Peter Jeremy, Poul-Henning Kamp, Ian Lepore, Xin LI, Warner Losh, and George Neville-Neil.

Compile other short articles on things that &os; does really well. Of particular interest are features that make life easier for sysadmins, or how problems on other systems are dealt with or even made non-problems on &os;.

 The &os; Core Team &os; Core Team core@FreeBSD.org

The &os; Core Team constitutes the project's "Board of Directors", responsible for deciding the project's overall goals and direction as well as managing specific areas of the &os; project landscape.

In order to help attract fresh developer talent to &os;, Core has a general policy to make available an up-to-the-minute suite of developer tools and services. Core has long been encouraging &os; committers to make full use of the project's Phabricator instance at https://reviews.FreeBSD.org, and now has supported the Phabricator admins in opening access to anyone interested enough to sign up for an account.

Further developments under consideration include setting up a FreeBSD.org oauth2 provider and permitting oauth-style Single Sign-On access to most FreeBSD web-based services. Developers and members of the public would additionally be able to use credentials from other providers such as GitHub, Twitter, or Google to authenticate themselves to &os; web services.

Mark Murray raised a problem he has been having for some time with getting adequate security review of his proposed changes to random(9). This is an extremely security sensitive area of the kernel where errors can have disastrous consequences. Core has been able to drum up a number of reviewers and they have made significant progress in simplifying the design, eliminating some difficult portions of code, and reducing any potential attack surface. Work is still ongoing and Core remains open to the idea of bringing in external reviewers with specialist cryptographic knowledge.

Dag-Erling Smørgrav resigned as Security Officer towards the end of May. Core was sorry to see him step down, but unanimously pleased to welcome his nominee and former deputy, Xin Li, as his successor. Xin has since appointed Gleb Smirnoff (who also happens to be a current member of core) as his new deputy. Between them and Core they have some fairly radical ideas under discussion about how to improve the project's responsiveness to security issues.

Shortly after BSDCan in mid-June, Warner Losh proposed a change to style(9) which resulted in some lively discussion. An informal poll was conducted via Phabricator and the change was committed within a couple of days. Unfortunately, this did not meet with universal approval and Core was called upon to arbitrate. Warner backed out the change, recognizing that there had not been enough time allowed for proper discussion. Many people were still in transit from BSDCan, and the voting arrangements did not suit everyone. A new poll has since been held, with votes either by e-mail or the Slowvote facility of Phabricator. This resulted in approval of the change by a wide margin.

During this period we had two new commit bits awarded, and one taken in for safekeeping. Welcome aboard to Chris Torek and Mariusz Zeborski, and we were very sorry indeed to see Steve Kargl decide to call it a day.

 CloudABI: Capability-Based Runtime Environment Ed Schouten ed@FreeBSD.org CloudABI on GitHub FreeBSD patchset on GitHub

CloudABI is a compact UNIX-like runtime environment that is purely based on capability-based security (Capsicum). All features that are incompatible with this model have been removed. Advantages of using a pure capability-based environment include improved security, testability, and reusability. CloudABI should make it possible to run arbitrary third-party executables directly on top of &os; without any impact on system security, making it a good building block for a cluster/cloud computing setup. See the project on GitHub for a more detailed explanation.

Last month I added a number of packages for the &os; Ports tree. We now have a full C/C++ cross compiler that can be installed very easily (devel/cloudabi-toolchain). I also imported a tool called cloudabi-run that can be used to start programs safely, only granting access to files and network sockets listed in the program's configuration file (sysutils/cloudabi-utils).

I have also imported some kernelspace modifications into the &os; source tree for executing CloudABI programs. After all of these changes have been imported, just loading a kernel module will allow executing CloudABI programs. Right now, the "cloudabi" branch on GitHub is still required.

Nuxi, the Netherlands

Polish up the kernelspace modifications and send them out for review.

Complete the Linux and NetBSD kernel patchsets and send those out to the respective maintainers.

 Sleep States Enhancements on <tt>x86</tt> Konstantin Belousov kib@FreeBSD.org

The ACPI specication defines CPU Cx states, which are idle states. Methods to enter the state and miscellaneous information like state leave latency are returned by the _CST ACPI method. To save energy and reduce useless heating, the operating system enters the Cx state when the CPU has no work to do. C0 is the non-idle state, while C1, C2, and C3 (defined by ACPI) each represent an idle state with sequentially more energy saving, but also with higher latency of leave and possibly greater secondary costs. For example, C1 is entered by executing the HLT instruction and has no architecturally visible side effects, while entering C3 drops the CPU cache and usually requires special chipset programming to correctly handle requests from I/O devices to the CPU. Do not confuse Cx, Px and Sx: Cx states are only meaningful when the system is in fully operational state S0; Px states are only meaningful when the system is not in the idle state, C0.

Modern Intel CPUs enter Cx (x >= 1) states with the dedicated instruction MWAIT, which enters a specified low-power state until a specific write is observed by the CPU bus logic. There is a complimentary MONITOR instruction to set the monitored bus address. The legacy port I/O method of entering Cx state is emulated by CPU microcode, which intercepts the port I/O and executes MWAIT internally. Using MWAIT as the method of entering Cx requires following processor-specific procedures, which are communicated to the operating system by the vendor-specific extensions in _CST. The operating system must indicate readiness to support MWAIT when calling _CST. Claimed benefits of using MWAIT are reduced latencies of leaving the idle state, and visibility of more deep states than defined by the common ACPI specification. Still, modern Intel platforms report deep states as C2 to avoid the not needed bus-mastering avoidance.

The new code asks ACPI for the Intel vendor-specific _CST extensions, parses them, and uses MWAIT Cx entrance methods when available. The change was committed as r282678 to HEAD.

For Linux, Intel provides a driver which does not depend on the ACPI tables to use MWAIT for entering Cx states. For all Intel CPUs after Core2, the driver contains the description of the Cx mode latencies and quirks, eliminating dependency on the correct BIOS information, which is often incorrect. The approach of porting the Linux driver was considered by several people, but all evaluators independently concluded that the project cannot maintain such an approach without direct involvement from Intel.

During the work, around 500 lines of identical code between the i386 and amd64 version of the idle handling were moved to the common location x86/x86/cpu_machdep.c. Now the i386 and amd64 machdep.c files contain only unique machine-dependent routines. This advance depended on John Baldwin's elimination of the unmaintained Xen PVM i386 port.

The FreeBSD Foundation Rewritten PCID Support Konstantin Belousov kib@FreeBSD.org

Process-Context Identifiers (PCIDs) is a feature of the Translation Lookaside Buffer (TLB) on Intel processors, introduced with the Sandy Bridge micro-architecture. It allows the TLB to simultaneously cache translation information for several address spaces, and gives an opportunity for the operating system context switch code to avoid flushing the TLB on the process switch. Each cached translation is tagged with some context identifier, and at context switch time, the operating system instructs the processor which context is becoming active. The feature slightly reduces context switch time by avoiding flush, and more importantly, it reduces the warm-up period for the thread after a context switch.

&os; already used PCID, but the existing implementation had several shortcomings. The amd64 pmap (the machine-dependent portion of the virtual memory subsystem) maintained a bitmap of all CPUs which ever loaded a translation for the given address space, and avoided TLB flush on the context switch. The bitmap was used to direct Inter-Processor Interrupts to the marked CPU when the operating system needed to perform TLB invalidation. The most important deficiency of the implementation is the increase of TLB invalidation IPIs since the bitmap could only grow until full TLB shootdown is performed. It increases the TLB rate, which negated the positive effects of avoiding TLB flushes on large machines. Secondarily, the bitmap maintenance in both the pmap and the context code was quite complicated, leading to bugs. These issues resulted in the PCID feature being disabled by default.

The new PCID implementation uses an algorithm described in the U. Vahalia book "UNIX Internals: The New Frontiers". The algorithm is already used, for example, by the MIPS pmap for assigning the ASIDs to software-managed TLB entries. The pmap maintains a per-CPU generation count, which is assigned to the next unused PCID when the context is activated on CPU. TLB invalidation includes resetting the generation count, which causes reallocation of PCID when a context switch is performed. As result, the new implementation issues exactly the same amount of shootdown IPIs as pmap which does not utilize PCID.

 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) have 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 beta phase. Recent additions include:

In addition, the iser driver has been and continues to be thoroughly tested. The test suite includes:

The code is ready for inclusion and will be released under the BSD license.

Mellanox Technologies Root Remount Edward Tomasz Napierala trasz@FreeBSD.org

One of the long missing features of &os; was the ability to boot with a temporary rootfs, configure the kernel to be able to access the real rootfs, and then replace the temporary root with the real one. In Linux, the functionality is known as pivot_root. The reroot projects aims to provide similar functionality in a different, slightly more user-friendly way: rerooting. Simply put, from the user point of view it looks like the system performs a partial shutdown, killing all processes and unmounting the rootfs, and then partial bringup, mounting the new rootfs, running init, and running the startup scripts as usual.

The project is in the late implementation phase. A working prototype was written, and work is in process to rewrite it in an architecturally nicer way.

The FreeBSD Foundation

Complete debugging

 Ports Collection Frederic Culot portmgr-secretary@FreeBSD.org &os; Ports Management Team portmgr@FreeBSD.org

As of the end of Q2, the ports tree holds nearly 25,000 ports, and the PR count is about 1,800. Once again the tree saw more activity than during the previous quarter, with almost 8,000 commits performed by 153 active committers. On the other hand, the number of problem reports closed decreased slightly, with a bit less than 1,700 problem reports fixed.

In Q2, several commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (clsung, dhn, obrien, tmseck), or on committer's request (sahil). Two new developers were granted a ports commit bit (Michael Moll - mmoll@, and Bernard Spil - brnrd@).

On the management side, pgollucci@ started his four-month term as portmgr-lurker in June, and no changes were made to the portmgr team during Q2.

This quarter also saw the release of the second quarterly branch, namely 2015Q2. On this branch, 39 committers applied 305 patches, which is more than twice as many updates as during the last quarter.

On QA side 30 exp-runs were performed to validate sensitive updates or cleanups. Amongst those noticeable changes are the update to pkg 1.5.4, three new USES (waf, gnustep, jpeg), Perl switch to 5.20, Ruby to 2.1.6, Firefox 38.0.6, and Chromium 43.0.2357.130.

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 2015 Q1, but as always, any additional help is greatly appreciated!

 OpenBSM Robert Watson rwatson@FreeBSD.org Christian Brueffer brueffer@FreeBSD.org TrustedBSD audit mailing list trustedbsd-audit@TrustedBSD.org

OpenBSM is a BSD-licensed implementation of Sun's Basic Security Module (BSM) API and file format. It is the user space side of the CAPP Audit implementations in &os; and Mac OS X. Additionally, the audit trail processing tools are expected to work on Linux.

After a period of dormancy, the project is slowly picking up steam again. The OpenBSM source code repository was migrated from &os;'s Perforce server to GitHub. We hope this will make the code more accessible and stimulate outside contributions. In addition to the repository migration, initial steps towards a new test release have been made.

Test the code on GitHub on different releases of Mac OS X and Linux

 Address Space Layout Randomization (ASLR) Shawn Webb shawn.webb@hardenedbsd.org Oliver Pinter oliver.pinter@hardenedbsd.org HardenedBSD core@hardenedbsd.org HardenedBSD True Stack Randomization Announcing ASLR Completion Call for Donations SoldierX

HardenedBSD is a downstream distribution of &os; aimed at implementing exploit mitigation and security technologies. The HardenedBSD development team has focused on several key features, one being Address Space Layout Randomization (ASLR). 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 vulnerability lies in memory.

This last quarter, the HardenedBSD team has finalized the core implementation of ASLR. We implemented true stack randomization along with a random stack gap. This change allows us to apply 42 bits of entropy to the stack, the highest of any operating system. We bumped the hardening.pax.aslr.stack_len sysctl(8) to 42 by default on amd64.

We also now randomize the Virtual Dynamic Shared Object (VDSO). The VDSO is one or more pages of memory shared between the kernel and the userland. On amd64, it contains the signal trampoline and timing code (gettimeofday(4), for example).

With these two changes, the ASLR implementation is now complete. There are still tasks to work on, however. We need to update our documentation and enhance a few pieces of code. Our ASLR implementation is in use in production by HardenedBSD and is performing robustly.

Additionally, we are currently running a fundraiser to help us establish a not-for-profit organization and for hardware updates. We have received a lot of help from the community and we greatly appreciate the help. We need further help to take the project to the next level. We look forward to working with the &os; project in providing excellent security.

SoldierX

Update the aslr(4) manpage and the wiki page.

Improve the Shared Object load order feature with Michael Zandi's improvements.

Re-port the ASLR work to vanilla &os;. Include the custom work requested by &os; developers.

Close the existing review on Phabricator.

Open multiple smaller reviews for pieces of the ASLR patch that can be split out logically.

Perform a special backport to HardenedBSD 10-STABLE for OPNSense to pull in.

golang segfaults in HardenedBSD. Help would be nice in debugging.

 + + + OPNsense + + + + + Franco + Fichtner + + franco@opnsense.org + + + + + Ad + Schellevis + + ad@opnsense.org + + + + + Jos + Schellevis + + jos@opnsense.org + + + + + OPNsense website + OPNsense source code + + + +

OPNsense is a fork of pfSense that aims to follow &os;'s + code base and ecosystem quickly and closely while retaining + the parent's powerful firewall capabilities. The new 15.7 + release includes efforts such as firmware upgrades and + packaging fully based on pkg, weekly security + updates, the replacement of ALTQ-based traffic shaping with + IPFW/dummynet, and production-ready LibreSSL integration as an + alternative to OpenSSL.

+ +

Contributors and testers are welcome as we work on + redesigning plugin support, rework the GUI according to modern + coding standards (MVC) and privilege separation.

+ + + + Deciso + +