RISC-V is a new, completely open instruction set architecture from UC Berkeley, the birthplace of BSD. Berkeley has released a BSD-licensed processor implementation (Rocket), and they are building up a full software ecosystem for RISC-V. In this talk, I will describe the current status of FreeBSD on RISC-V -- as well as the larger RISC-V hardware and software ecosystem.

This presentation is based upon the work of five authors:

Jonathan Anderson, Brian Kidney, George Neville-Neil, Arun Thomas, and Robert Watson.

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.

While poudrière is a tool designed to build and test packages for FreeBSD, it has been recently extended to be able to build custom images of FreeBSD, allowing to easily build applicances, custom ISO images, custom USB stick, custom virtual machine VM, FreeBSD based firmware.

This talk will explain the story behind poudriere image, how it works, and how one could use it.

Since their introduction in the early 1980s, the mmap family of system calls (madvice, mprotect, munmap, etc) have become the dominant method for managing virtual address space in UNIX systems. Virtually all important programs and runtime environments have abandoned the older sbrk heap management interface. While mmap is serving us well, it has a number of shortcomings including weak support for mitigation technologies like W^X. In this talk I highlight the deficiencies of mmap and propose a new family of interfaces in hopes of providing a firm footing for the next 30 years of UNIX programmers.

High Performance Computing (HPC) is the highly CPU-, memory-, I/O-, and communication-intensive use of resources for computational simulations. It is commonly employed in science and engineering. Today's HPC installations are rapidly approaching the exaflop barrier. The research conducted on them reaches from furthering our basic understanding of the universe, to designing and analyzing materials for tomorrow's products. FreeBSD does not have an extensive pedigree as a HPC system; however, its design is, maybe uniquely, fitting for HPC development. Hence, the project should attempt to attract more HPC developers, as this would open avenues for novel use cases and enlarge the pool of talent available to the project. More importantly, parts of the HPC stack of codes are dependencies of commonly used mainstream applications, such as media players or desktop environments. HPC technologies also disseminate and trickle down into tomorrow's technological mainstream. This fact logically implies that there are benefits to being early part of the technological development cycle. It allows us to shape it from the onset as opposed to laboriously porting results later and stripping out incompatible, OS-specific hacks on the fly. I want to convince fellow BSD developers and users that HPC is not just an exciting technological corner case, but instead has real-world, daily impact on most BSD installations.

This talk will introduce the technologies that matter for HPC and their status within the FreeBSD project. We will discuss all important parts of the HPC tool chain in the context of FreeBSD's ecosystem and ports infrastructure. We will start with languages in HPC (Fortran, C/C++, and hybrids thereof) and compiler support (LLVM and GCC-based toolchains and their mixing), via parallelization and communication technologies (OpenMP, MPI) and fundamental numerical libraries (BLAS/LAPACK, FFTW) to end with the daily experience of porting HPC libraries and applications to FreeBSD and developing, maintaining, and optimizing them primarily there. Special emphasis will be given to one of the most disruptive technologies in HPC in the last decade: GPU acceleration. I will discuss which GPUs FreeBSD supports for acceleration and what the current possibilities and limitations are. An outlook to potential future development in this area under the umbrella of the linuxkpi-based DRM import project will be given.

Finally, the talk will lay out what changes to the FreeBSD ports ecosystem would improve the experiences of HPC developers and users alike.

The bhyve hypervisor in FreeBSD was initially targetted at server virtualization, with only an emulated serial console provided for direct user access to the system.

While this satisfied the needs of a small user base, installation was difficult since it often required modification of installation media, and sometimes long and arcane procedures to bring the system to a point where alternate system access, such as SSH or RDP, could be enabled. Some guest operating systems did not allow any form of installation over a serial port. This barrier was enough to prevent many from wanting to use bhyve.

To solve this issue, additional device emulations for a graphics adapter, keyboard and mouse were added to bhyve, along with a VNC server to provide access to these. This subsystem is collectively known as "bhyve graphics", and has greatly simplified the installation and use of many guest operating systems.

This talk describes the motivation, design and implementation of bhyve graphics, along with some possible future directions.

ZFS is an advanced filesystem, but that doesn't mean it is complicated or hard to understand.

After an overview of the basics of what ZFS is and how it works, we'll delve into how to integrate ZFS into a system or product.
Topics to include:
* Boot Environments and how to use them
- new boot environment management tool and library from Google Summer of Code
- case studies / use cases
* Advanced Boot Configuration (zfsbootcfg/nextboot)
- Boot the new system image only once
- Fall back to previous version if new system image fails to stay up for 5 minutes three consecutive times
* Automated Boot Recovery (Appliance style failover/failsafe)
- Fall back to rescue image if system fails to boot repeatedly (required for environments like Amazon where there is no console)
* GELI Encryption Support
- Improvements to allow unattended booting
* Appliance Upgrading with ZFS (including zpool checkpoints)
- Create a checkpoint before upgrading an appliance, revert to checkpoint if upgrade is not completely successful. Checkpoints can undo things that a snapshot cannot, like renaming or destroying an entire filesystem.

Techniques discussed will be of interest to most everyone, from users and developers for laptops and servers, to appliance manufacturers, and embedded products.

Often times "security" is equated with strong passwords and difficult-to-configure subsystems --
thereby suggesting the practices of system administrators & users are responsible for keeping systems safe. But obviously programmers should keep improving the State of the Art. Theo de Raadt has 25 years experience selecting security features from papers/conversations, or designing them from scratch with his team. These "tweaks" are refined and injected into the vast OpenBSD ecosystem, enabled-by-default, thereby proving they are viable, and paving the way for other operating systems to adopt eventually. Stack protecter, ASLR, pervasive random use, W^X, Stackghost, privsep, fork+exec, and recently pledge -- let's see if there are some lessons in common about this area of work.

FreeBSD port to RISC-V 64-bit Instruction Set Architecture (ISA) was added in January 2016. FreeBSD is the first operating system that officially supported RISC-V in the main repository. Since its introduction the support was evolved, RISC-V privileged architecture was updated few times. The platform becomes more and more mature and suitable for general and commercial usage, research and education.

GCC v7.0 target for RISC-V was officialy upstreamed, NVIDIA is planning to ship all of their GPUs with RISC-V coprocessor enabled. Few companies announced RISC-V chips development start and many universities are taking RISC-V as a target architecture for doing research. The world first RISC-V microcontroller-class board HiFive1 was released and we are getting closer to the first general purpose board to become available!

In my talk I will mainly describe the current status of FreeBSD/RISC-V, toolchain and simulators supported. And I will make short attention to the porting process itself, as well as describing the latest changes we had to make to FreeBSD in order to support the latest RISC-V privilege specification (v1.10). This includes enabling by default FDT support and drivers attachment change, SBI interface, compiler flags/built-in defines change, support for updated BBL boot loader, RISC-V privilege levels, initial page tables build, page table entry flags and other changes.

As additional, I plan to make an overview of FreeBSD device drivers subsystem. This should answer the question: How to write device driver for FreeBSD/RISC-V? I will describe the device frameworks, buses and kernel-interfaces that exists in FreeBSD (e.g. Newbus, cdevsw, bus_dma, SYSINIT, vt, sound, ifnet, spibus, etc etc) and will try to answer the question how to use it, how to configure and how to debug device driver.

Capsicum is a sandbox framework in the FreeBSD operating systems and it's based on the capabilities concept. Programs running in a sandbox don't have access to any global namespaces (such as lesytem or network namespace). Last year was very productive for Capsicum. More people got involved in the project and new interesting features were developed. However, most importantly a lot of applications from base systems were sandboxed.

With a growing number of sandboxed applications we also recognized new kinds of problems. Some of them we've already managed to solve. The

FreeBSD community was able to sandbox around 22 new applications re-cently, but it's still long way from sandboxing all of them.

One of the thing we noticed during that process is a large chunk of code which we needed to rewrite multiple times in different programs. To simplify the use of this framework we introduced Capsicum helpers, a small C header of few inline functions which allows to reduce repeating parts of codes. One of very common thing is to limit standard output and input descriptors, this forces us to copy paste around 15 lines of code.

Thanks to simple API caph_limit_stdio() we are able to limit it to 2 lines of code. The header provides us also more grainy API for every descriptor:
• caph_limit_stdout
• caph_limit_stdin
• caph_limit_stderr

As well as generic function caph_limit_stream which can limit any descriptor provided. All those function are limiting descriptor to the most common ioctl and capability rights. Capsicum helpers also provides a few functions which allows to cache some common used data. For example localtime need to read once /etc/localtime.

If localtime function is called after entering sandbox then function will get bad time. The caph_cache_tzdata function was introduced to cache time zones les. One of the reasons of collecting such functions is also documenting for developers which things need to be cached before entering Capsicum.

A very common problem of Capsicum is silent failures. When sandbox is added to an application, a developer cannot notice some conditions of program. For example if an application is using a library and this library is using random number generator by opening /dev/random if possible and otherwise use some insecure random generator. If a developer will not no-tice this behavior by analyzing the code this can lead to introducing new bugs while snadboxing application. One way is to use ktrace infrastructure but this also can be unnoticed by developer. Due to the new debugging feature for Capsicum which was implemented by Konstantin Belousov under FreeBSD foundation sponsorship. Enabling procctl(PROC_TRAPCAP) (per-process) or sysctl kern.trap_enocap (globally in the system) kernel will issue SIGTRAP to generate a core dump or enter the debugger incited of returning ENOTCAPABLE or ECAPMODE.

Some sandboxed applications had very interesting stories, like dd. One of the problem we encountered was that dd is a build tool. Another one was the problem which overrating stderr descriptor. Case studies of sandboxing applications like that can be very educational for future developers.

Despite being a relatively small fraction of the kernel by lines of code, the memory management subsystem of the FreeBSD kernel has a number of complex responsibilities. A non-exhaustive list includes: implementing the virtual memory abstraction for user-mode processes; gracefully handling memory shortages; providing a general-purpose memory allocator to other kernel subsystems (the kernel needs malloc() too!); sharing physical memory with peripheral devices such as GPUs; and tight integration with file systems to provide interfaces such as mmap(2) and sendfile(2).

If that wasn't enough, this subsystem must be efficient and ideally scales well to arbitrarily many CPU cores, and it should be able to take advantage of platform-specific hardware features that provide performance benefits. These constraints and requirements result in a level of intrinsic complexity that can make the code in sys/vm/ seem daunting to a newcomer.

The last two years have seen a large number of incremental refactorings and optimizations in that core portion of the FreeBSD kernel that manages physical and virtual memory on behalf of the rest of the system. This talk aims both to highlight these recent changes, and to use them to provide high-level introductions to the structure of FreeBSD's memory management code. Examples of recent changes include the removal of PG_CACHED pages; the PQ_LAUNDRY page queue; the MAP_GUARD flag for mmap(2); optimizations to the existing support for superpage mappings; and a scalability improvement in execve(). The talk also aims to describe some in-progress changes that seek to remove bottlenecks currently seen on many-CPU systems, and to describe some of changes needed to improve performance on NUMA systems