vBSDcon 2017

• Watch the presentation

GELI Support for UEFI, by Eric McCorkle

Dr. Kyle Kneisl

We exist in a delicate balance and special niche. The world is moving quickly to embrace operating systems concepts that are not particularly associated with BSD.

Though we remain vibrant today, we are more at risk than the competition, especially in terms of pipeline dynamics. As our average age creeps up, what are the organic vectors in place to bring new blood into the community? What is our argument for relevance? What are the challenges? To what problems are we the unique solution? What business and cultural mistakes are we making, right now, that have unintended consequences for our long-term viability? Where does FreeBSD respond best to new problems that the hobbyist-level general public now confronts? Where has the FreeBSD community seen the most organic, new growth and depth of participation in the past several years?

These questions have answers, many of them surprising and unexpected. Now is the time to put these questions on the radar, and to make their answers part of our collective discussion. The past twelve months have seen some close shaves that many have not noticed that had the potential knock pegs out from under our relevance in ways that would be hard to rectify. The situation is, perhaps, more delicate than we broadly understand. But there is good news: we find ourselves in the right place, at the right time. It is our appliances which showcase our best achievements---and the unbelievably dynamic communities around them---that can be our salvation, for these are the places that new blood is seeing that we are the best and have no competition. If we do it right.

• Watch the presentation

Isolated BSD build environments using virtual and hardware machines, by Michael Dexter

Michael Dexter

The rapid pace of BSD development results in a steady flow of new features at the risk of an equally-steady flow of bugs and regressions large and small. Software flaws can, and have remained undetected for decades and been included in formal releases. The difficulty of isolating operating system regressions has traditionally increased proportionately to the age of the software under scrutiny, requiring equally dated build environments. While the BSDs are exemplary as self-hosting operating systems, this independence is not guaranteed between recent or distant generations of the OSs.

This talk will describe a strategy for using device and PXE-booted virtual machines, plus PXE-booted hardware machines to create isolated build environment that allow for arbitrary source repository revisions to be built under arbitrary OS releases snapshots. While developed with FreeBSD and bhyve with the option of QEMU and jail(8) for extreme regression tracing, this strategy could equally apply to OpenBSD/vmm and NetBSD/Xen.

Michael is a BSD Unix-related author, trainer and support provider who has spoken at BSD conferences since 2008. Michael helped usher the bhyve and Xen hypervisors into FreeBSD and sponsored the SysJail jail mechanism for OpenBSD.

• Watch the presentation

Deep Dive into FreeBSD's Kernel RNG, by John-Mark Gurney and Dean Freeman

Dean Freeman and John-Mark Gurney

Deep Dive into FreeBSD's Kernel RNG walks through the entire chain, from initializing the entropy subsystem at boot through delivery to userland applications via random devices, sysctls or APIs such as arc4random. It includes an evaluation of how entropy is collected for use while the system is running. The paper includes an evaluation of how the different RNG pools are loaded, as well as empirical measurements of the quality of entropy being fed into the PRNG in keeping with NIST's SP800-90A assessment methodology.

• Watch the presentation

Oblivious sandboxing: developments in transparent sandboxing with Capsicum, by Jonathan Anderson

Jonathan Anderson

Application compartmentalization (a.k.a., sandboxing) can be used to protect applications from themselves and protect users from misbehaving applications. However, the current state of the art requires applications to be willing participants: invasive modifications are required, and it's up to the application whether or not it will voluntarily sandbox itself. We would like to move towards a world in which applications can be started from within compartments (created with technologies like Capsicum) and have their access to global namespace like filesystems transparently mediated. This approach may never scale to applications with complex event models like web browsers, but we believe that there is a great deal of mileage to get out of it with more straightforward (though still sophisticated) applications like compilers.

This talk will describe recent work in FreeBSD that is driving at the goal of transparent, oblivious sandboxing. We will discuss changes in the ELF image activator and run-time linker to support transparent sandboxing as well as a support library for managing pre-opened directory descriptors and a simple shell application to start applications from within sandboxes. Together, these techniques allow us to take a few more steps towards our goal of usefully confining applications whether they like it or not.

• Watch the presentation

The State of Network Security Tools on BSD, by Michael Shirk

Michael Shirk

Network Security Monitoring (NSM) is the foundation of monitoring a network for potential intrusions and extrusions. Security tools like Snort, Suricata, and Bro create network logs to assist with investigating potential intrusions. There always seems to be interest on the Snort, Suricata, and Bro mailing lists for running open source security tools on BSD operating systems. The goal of this talk will be to describe the current state of open source security tools running on the various BSD operating systems, and what technology can assist with moving more security monitoring back to BSD. There will also be a discussion on log management, and what solutions are available for BSD operating systems.

In the early days of BSDCon, and the DC area BSD conferences, there was great interest in the use of BSD operating systems for Network Security Monitoring (NSM). Tools such as Sguil showcased the entire process of incident response using just FreeBSD. Since the early 2000s, security companies have moved away from BSD operating systems to use Linux based sensor platforms (even Security Onion, the most popular platform for NSM runs on Ubuntu). Although there were performance gains at the time to change (for things like SMP), Linux systems have grown to be much more annoying than running Windows systems due to complexity and security vulnerabilities. In 2016, with the growing concern on the direction of the various Linux distributions, there has been interest in moving to a sensible UNIX platform for network security tools. I have been pushing for the evaluation of BSD network sensors as high performance network sensors, ideally with commodity hardware, but also with the addition of specialized network cards.

The goal of this talk will be to provide an overview of the current network security tools available for the BSD operating systems, how to utilize them on each operating system, including any special tweaks for security or performance, and to advocate for their use on BSD operating systems. This talk will discuss my experience representing the BSD community at BroCon and SuriCon 2016, and other anecdotal information about the various network security tools. The talk will also cover the managing of log data, as this has been a point of contention recently with the tools that are available and open source for storing logs files.

• Watch the presentation

Making gets() and its Friends more like SIGPIPE and SIGILL, by Paul Vixie

Paul Vixie

In the decades since the Morris worm, BSD has substantially modernized, which has included tracking ANSI C and POSIX LibC. Portability was seen as necessary for relevance and success, and for the most part, it has been. There are some exceptions, and it's long past the time when we should have made some hard but sensible choices about what to include or emulate, and what to leave out, and what to poison outright.

• Watch the presentation

BSD Systems Management with Ansible, by Benedict Reuschling

Benedict Reuschling

Traditionally, shell scripts have been used to apply changes to a Unix system in an automated way. As systems became more diverse (OS versions, patch-levels, etc.) and the number of systems a sysadmin to manage typically grows over time, this classic approach is showing some drawbacks. For example, how do you deploy a change across multiple machines simultaneously in a consistent way? Ansible is a system administration and automation tool to help solve these problems. It can deploy ad-hoc commands or complex scripts (called playbooks) in parallel via SSH to multiple machines. It also supports idempotency, which, in a nutshell, means that a change is applied only once, not multiple times and the system state only changes when said change has not been applied before. In shell scripts, this would require a lot of additional if-then-else checks, which increases the maintenance time and effort. With Ansible, this is already built-in and system administrators can make use of it right away.

This talk will give an overview of how to convert shell scripts to Ansible, including tips and tricks for beginners. My examples are based on my own efforts in managing the Big Data Cluster at the University of Applied Sciences, Darmstadt, Germany with Ansible and the journey it took (and is still ongoing). This is a mixed environment with Linux and FreeBSD machines, (although the trend goes towards the latter) and I will show what sysadmins have to be aware of when using Ansible to manage different OSes. Ansible is not perfect and I will elaborate some of the shortcomings at the end of the talk. Beginners who are new to Ansible will get a good introduction to get started using it, while sysadmins will get an insight into how system administration in a university.

• Watch the presentation

The History and Future of Core Dumps in FreeBSD, by Sam Gwydir

Sam Gwydir

Crash dumps, also known as core dumps, have been a part of BSD since its beginnings in Research UNIX. Though 38 years have passed since doadump() came about in UNIX/32V, core dumps are still needed and utilized in much the same way they were then. However, as underlying assumptions about the ratio of swap to RAM have proven inappropriate for modern systems, several extensions have been made by those who needed core dumps on very large servers, or very small embedded systems.

We begin with a background on what core dumps are and why operators might need them. Then several timelines are used to characterize the changing nature of the core dump procedure in FreeBSD, with the side effect of providing a history of architecture support from UNIX v6 through to FreeBSD 12. Following that the current state of the core dump facility and some of the more common extensions in use are examined.

We conclude with my experience porting Illumos' ability to dump to swap on a ZFS zvol to FreeBSD and what that provides the operator.

In addition, a complete history of core dumps in UNIX and BSD was produced as research for this paper and can be found in the appendix.

• Watch the presentation

Modern Multicore Synchronization and Concurrency Kit, by Samy Bahra

Samy Bahra

Concurrency Kit was recently merged into the FreeBSD kernel, bringing along with it a myriad of primitives for high performance concurrent programming. This talk will examine what Concurrency Kit brings to the table and where it can be applied. The talk covers a wide array of topics ranging from memory management, to fast data structures, synchronization primitives and fairness.

Despite more than 20 years of active research and development, non-blocking technologies remain inaccessible to many students, engineers and open-source projects. This is especially true in the context of an unmanaged language such as C despite its popularity in highly complex concurrent systems. Even in light of attractive performance properties, small to medium-sized corporations are extremely hesitant in adopting patent-free technology due to the technology lock-down associated with the various interfaces of existing concurrency libraries. To top it off, when introducing engineers to this area, many are overwhelmed by the literature and the sparsity of performance data.

This talk will walk the audience through the story of the struggles Samy and his peers have faced in the last couple of years in developing sufficient working knowledge to (efficiently) leverage existing non-blocking data structures as well as design, implement and verify new algorithms for use by mission-critical systems. It will highlight the holes faced in existing open-source projects tackling the concurrency problem for the C programming language and the literature associated with much of existing technology. The culmination of frustrations leads to the development of Concurrency Kit, a library designed to aid in the design and implementation of high-performance concurrent systems that has now been merged into the FreeBSD kernel. It is designed to minimize dependencies on operating system-specific interfaces and most of the interface relies only on a strict subset of the standard library and more popular compiler extensions.

• Watch the presentation

The Realities of DTrace on FreeBSD, by George Neville-Neil

George Neville-Neil

For more than a year we have been using DTrace as one of the three core components of a security research project, CADETS. Unlike earlier users of DTrace, which were focused on occasional, deep debugging sessions, the CADETS project uses DTrace to bring total system transparency to both the operating system and the applications that are running on top of it. The use of "always-on tracing" pushes the DTrace system up to, and often, past its limits and shows how some of the original design tradeoffs need to be revisited to address the needs of our project. Our talk covers our current efforts to extend and improve the DTrace framework in FreeBSD, including performance and programming improvements to address the needs of always-on tracing as well as integration with FreeBSD's audit subsystem and the addition of machine-readable output for use by creators of downstream security-analysis tools. 

• Watch the presentation

Using pkgsrc for multi-platform deployments in heterogeneous environments, by G Clifford Williams

G. Clifford Williams

This talk covers the benefits of decoupling your application code from the packaging system that ships with your operating system. Unless the packaging system for your OS happens to be pkgsrc.

Need two incompatible versions of the same library installed on the same host? Want a different version of crypto libraries, compilers, or language runtimes than what comes out of the box with your default package manager? Docker style containers are currently all the rage, but they come at a cost and with several layers of indirection. Here we'll talk about a much simpler approach to hosting multiple versions of the same applications, tools, libraries, etc. in a conflict-free manner with the help of pkgsrc.

Specifically, we'll look at the reduced complexity in using tools like Salt, Chef, Ansible, and Puppet for orchestration and configuration management as well as ways to avoid the administrative overhead of using Jails, Zones, and LXC.

• Presentation video unavailable

Dr. Kyle Kneisl

We exist in a delicate balance and special niche. The world is moving quickly to embrace operating systems concepts that are not particularly associated with BSD.

Though we remain vibrant today, we are more at risk than the competition, especially in terms of pipeline dynamics. As our average age creeps up, what are the organic vectors in place to bring new blood into the community? What is our argument for relevance? What are the challenges? To what problems are we the unique solution? What business and cultural mistakes are we making, right now, that have unintended consequences for our long-term viability? Where does FreeBSD respond best to new problems that the hobbyist-level general public now confronts? Where has the FreeBSD community seen the most organic, new growth and depth of participation in the past several years?

These questions have answers, many of them surprising and unexpected. Now is the time to put these questions on the radar, and to make their answers part of our collective discussion. The past twelve months have seen some close shaves that many have not noticed that had the potential knock pegs out from under our relevance in ways that would be hard to rectify. The situation is, perhaps, more delicate than we broadly understand. But there is good news: we find ourselves in the right place, at the right time. It is our appliances which showcase our best achievements---and the unbelievably dynamic communities around them---that can be our salvation, for these are the places that new blood is seeing that we are the best and have no competition. If we do it right.