Jails are one of FreeBSD's greatest features. Students will learn:

• how jails achieve lightweight virtualization
• the base system's jail tools and the iocage toolkit
• how to optimally configure jail hardware
• how to manage jails from the host and from within the jail
• how to optimize disk space usage to support hundreds or thousands of jails
• how to comfortably work within the limits of jails
• to Implement fine-grained control of jail features
• how to build virtual networks
• how to deploy hierarchical jails
• how to constrain jail resource usage

This class is based on Lucas' book "FreeBSD Mastery: Jails."

System administrators experienced with FreeBSD

Michael W Lucas is a long-time sysadmin, network engineer, and author of three dozen books, including several on FreeBSD.

This tutorial is a hands-on session, featuring a live install of a pure FreeBSD/Xen system. We'll show how to setup FreeBSD as control domain and give live examples about how to create and run several different kind of guests on top of it.

By the end of the tutorial session the attendees should be able to setup their own FreeBSD/Xen install and be able to create and manage any kind of guest supported by the Xen Hypervisor.

Anyone interested in virtualization using FreeBSD and Xen. The tutorial should be suitable for any experience level, without requiring prior knowledge of Xen.

Roger Pau Monne is a Software Engineer at Citrix and a FreeBSD developer. He is currently working on maintaining and improving Xen support in FreeBSD. Apart from contributing to Xen and FreeBSD he also contributes to other related Open Source projects, like the Linux kernel and Qemu.

Nowadays a lot for workload (CPU, memory, IO) is moving to cloud because of cost consolidation and maintenance pain. Cloud is usually based on virtualization in order to ensure isolation between different workloads of the same client or different clients on the same hardware. In FreeBSD virtualization is provided by bhyve. In order to use bhyve as a hypervisor in cloud workloads it has to ensure two important features: checkpoint (snapshot) and live migration. Checkpoint is demanded by all clients in general when they need to to upgrade on their OS and in case something goes wrong to have a point in time where they can easily return. Live migration is used by cloud vendors in order to ensure high availability in case of hardware or operating system maintenance. This tutorial is about checkpoint and live migration features for bhyve: what is the design, what happens and how to use it.

The tutorial will be comprised of the following:

• short presentations (15 minutes) about the features: what code was modified, how they work, what are the limitations, what are the prerequisites
• after each theoretical presentation we will have a tutorial based hands-on exercise: enable feature and how to use that feature - step by step together with me
• at the end we aim to add some exercises for each individual to solve him self and ask questions to the tutor whenever is necessary

The target audience are the sys-admins which are running bhyve virtual machines and want to use the above presented features (checkpoint and live-migration).

As prerequisites, the participants should be comfortable with the FreeBSD CLI (90\% of the work will be done from CLI).

Mihai Carabas is an associate profesor at University POLITEHNICA of Bucharest. He has a PhD in mobile virtualization solutions and teaches classes from operating systems and computer architecture area. He started to work on BSD virtualization 6 years ago (first DragonFlyBSD vkernels and than FreeBSD bhyve). He has written the bhyveARM module and in the last three years he has been leading/coordinating students in developing bhyve features like bhyveARM64, virtio for bhyveARM, checkpoint, live migration and disk formats support. All this work that has been done at University POLITEHNICA of Bucharest is in the process of merging or reviewing, being pretty stable.

• What is Ansible and what not
• basic installation and configuration
• Introduction to key parts of Ansible
• Modules
• Inventory
• Variables
• Tasks, Plays, Handlers, Playbooks
• "Facts"
• Filters/lookup
• Templating
• Packaging ("libraries")
• Roles
• Galaxy
• Delegation
• .. there's more uncovered

Anyone interested in using Ansible - only basic BSD/Linux skills needed.

Philipp Buehler

There are situations where an existing database mechanism doesn't provide sufficient methods to determine the exact work being performed. An example of such situation is GIN index rebuilds as a result of the fastupdate mechanism and slow computation of query plans. Due to wrongly selected systems timers. With the help of DTrace, we will take a look on the Postgres internals and we show how a system administrator can clearly identify the root cause of a hanging insert and the slow computation of the query plans.

bhyve is the FreeBSD's type-two hypervisor. We have previously implemented warm and live migration options for bhyve. However, they have some limitations. In this paper, we present improvements added to the bhyve's live migration support in order to obtain a better performance. Moreover, we present the testing procedure and the results we obtained for warm and live migration. We compare the two migration methods and their downtime.

Elena Mihailescu is a PhD student in Computer Science at University Politehnica of Bucharest. Her domain of interests includes operating systems internals and computer security.

Describes how to add application programs to building FreeBSD systems on ZRouter.org. FreeBSD/arm uses qemu to create packages. This method is very complex and has poor performance. ZRouter.org uses the ports mechanism to build as an extension of buildworld. It also describes some collections that can be built with this mechanism.

In 1988, Hiroki Mori worked on porting 4.3 BSD at OMRON, then FreeBSD was started from around 1995 In 1999, I made bktr driver VBI support patch. 2000s Internet messaging service using FreeBSD It supported the system. In recent years I have used a module like a router in second hand and tried. I make sys/mips/atheros/ar531x and sys/arm/ralink. I like vintage soc.

Virtualization is an essential tool for various system administrators and cloud providers that enables hardware resource sharing and improves system security by isolating work environments. With servers powered by ARM systems getting closer to their more powerful, but more power hungry x86-based counterparts, being prepared to offer virtualization features is a must. A basic virtualization framework that allows creating virtual machines with CPU, memory and generic interrupt controller have been done, but getting the system ready for real-world applications is still a work in progress. To prove that the virtual machines can be used in scenarios that are more than the simplest of use-cases, we developed support for VirtIO devices and attempted to boot a Linux guest on top of them, since just a minimal install of FreeBSD using a few megabytes worth of storage as a ramdisk is simply not enough. In this paper we will present some of the work that we have done to get ready to boot a Linux guest using VirtIO device support from the hypervisor for low-overhead data transfers, the steps we have taken to prepare a Linux guest to boot under bhyve on ARM, and a few differences between Linux and FreeBSD, along with some issues that we have fixed.

Darius is a PhD Candidate at the University Politehnica of Bucharest. He started working on FreeBSD virtualization in 2017, with work on ARMv7 virtualization and cache functionality. Afterwards, he worked on starting a Linux guest under bhyve, with added support for VirtIO devices, and the save-restore mechanism for virtual machines on amd64 Intel systems. His domains of interest include operating systems, virtualization, security and hacking code together.

Containers have impacted how web services are developed, built and deployed nowadays. In more detail, Docker containers made available a different way of build and deploy services: the container con be build on a system and deployed in many copies on other systems. FreeBSD is an operating system that provides all the technologies needed to build a container model: jail, VNET, zfs, firewalls like pf or ipfw, rctl. In time, several tools have been developed to help sysadmin to manage jails. However, the typical jail management process is designed to build the jail directly on the host machine. The solution we propose aim to split the jail creation and the jail deploy, providing tools to create jail images via pot and deploying them using standard service mesh tools, like consul and nomad.

Born in Italy where I obtained my M.D. in Computer Science Engineering at Politecnico di Milano, I moved later in Germany where I start to work and enjoy FreeBSD. I've obtained my commit bit in the ports tree in August 2017. In 2018 I started to work at trivago, where I developed interests in containerized application and safe programming based on Rust.

The ZFS project started at Sun Microsystems in the summer of 2001 and has grown to be one of the most robust, relied upon filesystems available today. Over the course of its nearly 19-year history, it has continued to expand with additional features, and additional plat-forms. Far from being a legacy filesystem, ZFS is still on the leading edge of reliability and flexibility, while main-taining performance. After a brief review of the history of ZFS, this paper will explore the future of the OpenZFS project and FreeBSD’s role in it.

Allan Jude is VP of Engineering at Klara Inc., a global FreeBSD Professional Services and Support company. He also hosts the weekly video podcast BSDNow. A FreeBSD user since 2.2 and sysadmin since 4.5, became a FreeBSD docs committer in 2014, src committer in 2015, and was elected to the core team in 2016. In the spring of 2015, he published "FreeBSD Mastery: ZFS" with Michael W. Lucas, followed by "FreeBSD Mastery: Advanced ZFS" in 2016

The CHERI architecture allows pointers to be implemented as capabilities (rather than integer virtual addresses) in a manner that is compatible with, and strengthens, the semantics of the C language. In addition to the spatial protections offered by conventional fat pointers, CHERI capabilities offer strong integrity, enforced provenance validity, and access monotonicity. The stronger guarantees of these architectural capabilities must be reconciled with the real-world behavior of operating systems, run-time environments, and applications. When the process model, user-kernel interactions, dynamic linking, and memory management are all considered, we observe that simple derivation of architectural capabilities is insufficient to describe appropriate access to memory. We bridge this conceptual gap with a notional abstract capability that describes the accesses that should be allowed at a given point in execution, whether in the kernel or userspace. To investigate this notion at scale, we describe the first adaptation of a full C-language operating system (FreeBSD) with an enterprise database (PostgreSQL) for complete spatial and referential memory safety. We show that awareness of abstract capabilities, coupled with CHERI architectural capabilities, can provide more complete protection, strong compatibility, and acceptable performance overhead compared with the pre-CHERI baseline and software-only approaches. Our observations also have potentially significant implications for other mitigation techniques.w

Brooks Davis is a Senior Computer Scientist in the Computer Science Laboratory at SRI International and a Visiting Research Fellow at the University of Cambridge Computer Laboratory. He has been a FreeBSD user since 1994, a FreeBSD committer since 2001, and was a core team member from 2006 to 2012 and 2018 to present. Brooks earned a Bachelors Degree in Computer Science from Harvey Mudd College in 1998. His computing interests include security, operating systems, networking, high performance computing, and, of course, finding ways to use FreeBSD in all these areas.

Many UNIX-based operating systems are also used for embedded systems. Many current embedded systems use 32-bit system architecture, and 32-bit versions of UNIX based operating systems are often used. A 32-bit UNIX-based OS manages time information as a 32-bit signed integer, and it is known that an overflow of time information occurs in 2038. There are not many reports of practical approach for this problem. In this paper, we report our experience of successful modification of a 32-bit FreeBSD embedded system by changing the starting point of the UNIX time (epoch time). As a result, the system is guaranteed to be used beyond 2038 and it is now in the market.

Graduated from Kansai University Faculty of Engineering. Completed Graduate School of Culture and Science, The Open University of Japan. Currently studying at Osaka University Graduate School of Information Science. Engaged in software development since 1991. Professional Engineer, Japan (Information Engineering).

Multics first appeared in 1965, UNIX First Edition in 1969, 1BSD in 1977 and NetBSD 0.8 in 1993, followed by NetBSD 1.0 in 1994. The more modern versions: NetBSD 5.0 was released in 2009, 6.0 in 2012, 7.0 in 2015 and 8.0 in 2018. 8.0 was officially announced on July 16th, 2018. The NetBSD-8 branch was being developed as NetBSD-current between June 4th, 2017 and July 21st, 2019. NetBSD-9 was branched on 30th July and 708 pull requests (884 commits) were processed in the branch until the final release on February 14th 2020. The development period lasting 1.5 years brought a rich set of features to the distribution. These include: support for new hardware devices, massive improvements for the ARM 32-bit and AArch64 architecture, stub of RISC-V support, new hardware-assisted virtualization options, improved Wine support, kernel and userland sanitizers and fuzzers, security hardening and CPU bug mitigations, graphics stack upgrade, ZFS upgrade, debugging interfaces refinement, packet filter policy, 3rd party software upgrades, many bug fixes, generic enhancements and removals of obsolete code.

Kamil Rytarowski has been NetBSD users since 2013 and a NetBSD committer since 2015. He is also a team member of the EdgeBSD project with interest of NetBSD usability on desktop. Author of the .NET port to NetBSD, LLVM committer. In previous life GNU/Linux desktop user, enthusiast and since some point developer.

Nowadays fuzzing has become a state of the art technique in find-ing vulnerabilities. The procedure has evolved and now includes instrumenting the source code in order to improve the code coverage. Another set of tools that improve fuzzing is the sanitizers. Sanitizers are programming tools that detect bugs in the programs. There are a few types of sanitizers: Address Sanitizers (ASan), Undefined Behavior Sanitizers (UBSan), Thread Sanitizers (TSan) and Memory Sanitizers (MSan). There are sanitizers that are kernel specific: KASan, KUBSan, KTSan, KMSan. The use of sanitizers would reveal more vulnerabilities related to memory corruption (buffer overflows, access to a dangling pointer, disclose kernel memory to user space). FreeBSD includes support for the kernel coverage sanitizer(KCOV) and undefined behaviour sanitizer(KUBSAN), however support for the other sanitizers is missing. These are useful to find bugs while fuzzingthe kernel.The Kernel Address Sanitizer or KASAN is a fast and efficient memory error detector designed by developers at Google. It is heavily based on compiler optimization and has been very effective in reporting bugs in the Linux Kernel.The aim of my project is to build the FreeBSD kernel with the KASAN and use it to find bugs and improve code quality in the kernel. This Sanitizer will help detect a lot of memory errors that otherwise would be hard to detect.The focus of this paper is to explain the process of porting KASAN for FreeBSD. In 2018 Google Summer of Code, KASAN was ported from Linux to NetBSD. By now it has been developed and reached a mature state. The code is enormous and it is difficult to port as it is to FreeBSD. The strategy was to implement a basic support for KASAN in FreeBSD and then adhere to NetBSD codebase.The next step after porting is to use KASAN with other tools to find bugs. The syzkalleris a tool develop by Google’s Project Zero to perform fuzzing at kernel level. It is an unsupervised coverage-guided kernel fuzzer. Initially, syzkaller was developed with Linux kernel fuzzing in mind, but now it’s being extended to support other OS kernels as well.I also used syzkaller to perform fuzzing on Linux. This is where I learnt the power of syzkaller. It is currently running for FreeBSD, but without KASAN, it doesn’t reach its full potential. The first step is to create a shadow map of the FreeBSD kernel memory. This map is an actualy memory/buffer where each byte in the kernel is represented by using a bit. This means the size of the buffer would be 1/8th of the total memory accessible by the kernel. In amd64(also x86_64) this would mean setting aside 16TB of memory to handle a total of 128TB of kernel memory. So, when using KASAN, one must set aside a separate ”shadow buffer” memory. KASAN works by instrumenting all the memory accesses. The shadow buffer increases when memory is allocated and decreases when memory is freed. Before memory is accessed, the shadow map is questioned about the validity of the memory. Therefore, it legitimates a valid and an invalid access to memory.The first step is to create a shadow map of the FreeBSD kernel memory. At boot time, all shadow memory is poisoned. This means that the kernel memory is not allocated. While kernel memory is allocated, the shadow memory is unpoisoned. The second step is to look for all allocations and frees and call functions like kernel_poison_memory(&mem) for free functions and kernel_unpoison_memory(&mem) for allocations. These functions manipulate the shadow memory. The last step is to check the shadow map when memory is accessed. If a poisoned memory is accessed, a report should be created with the following information: the type of bug, whether a read/write caused it, PID of the task being executed, the address which caused the error and the stack trace which helps in identifying the function with the bug and also helps in finding the execution flow which caused the bug.

I'm a PhD student at Politehnica University of Bucharest. My area of research is Security on Mobile Systems. In the last few years I targeted Android and iOS as well as Linux. Part of my work is around fuzzing and black box testing.

The vnet enabled jails can configure its network stack using simple utilities like ifconfig(8). However, the system administrator may need to restrict this privilege. It may need the jail to follow a set of policy rules while setting its IP address on its virtual interface. These policy rules can be manually hacked into the kernel to impose desired restrictions, but it becomes very inflexible and difficult to tune. The sysadmin's work for managing the jail's network stack can be eased by using the mac(9) access control framework and a kernel module tunable with sysctl(8). The root of the host can thus input the desired policy rules using sysctl variables. Now, Whenever a jail request for an IP address, the MAC framework acts as a multiplexer and sends the request to the policy module using the hooks. The module may then allow or disallow the request after checking it with policy rules.

I'm B.Tech+M.Tech student in the Department of Electrical Engineering at IIT Kanpur, India. My interest area lies mostly in Operating Systems and Computer Networks.

The FreeBSD has three primary firewalls as of now; they are the pf, ipfw and ipf. These firewalls are used extensively in the networks worldwide, which brings in the need for a robust testing mechanism for these firewalls. In this article, we discuss a method to write tests for the firewalls using VNETs and also propose a method to write a common test for all the firewalls. An approach to writing common tests is required because the firewalls share a lot of common functionalities and writing tests for the same features of these firewalls independently brings in a lot of repetitive and redundant work.