BGP is becoming more and more relevant outside of pure networking. Developers need to understand TCP/IP for their own projects, micro-services use networking for performance and redundancy. Virtual Machines move from host to host, and need to have network traffic delivered to them. BGP is the backbone protocol of the Internet, and as a Data Center networking protocol for Facebook, Google, and Microsoft.

I will teach you the relevant basics of networking and how BGP is used in the wild. At my day job, I run the 4th most connected network in Germany, and are a developer with OpenBSD focusing on networking and OpenBGPD.

Attendees must bring a laptop that is able to connect to the local wifi or ethernet.

Everyone is welcome, this is specifically for non-experts and those who have no experience in networking.

Prior knowledge of subnets or routing is not required, but can be helpful.

Peter Hessler has been a developer with the OpenBSD project since 2008.

Monitoring is an essential part of every system administrators routine. Systems need to be automatically checked whether they are up, the services they offer are available, and if the metrics that are collected fall within defined thresholds. It is a valuable method to catch problems early, reacting to certain events like a full disk before it becomes a larger problem.

Traditionally, integrated systems solve a multitude of these problems. Software systems like Nagios are popular representatives of such monitoring systems. In this tutorial, we'll take a closer look at using and configuring the unofficial Nagios replacement called Icinga to cover our monitoring needs. Icinga is a modern system that builds on many of the concepts that made Nagios great, but adds their own, including a modern web interface. Plugins from Nagios can be used in Icinga without modifications and there is a whole ecosystem of new plugins available for Icinga.

The tutorial will introduce monitoring concepts to the audience by building a monitoring system based on Icinga from scratch. Together, we will look at how to install and configure the monitoring system on a BSD system (FreeBSD is used, but the concepts are applicable to other BSDs). Components that we're using in the turorial will be a combination of PostgreSQL and Nginx. PostgreSQL will store the monitoring information, while Nginx is used for the Icingaweb2 component, which provides us with a browser-based overview of the infrastructure we're monitoring. Basic concepts like how to define a host and a service to monitor are introduced. We'll mainly work in the config files that make up Icinga2 and don't do much configuration in the web UI itself.

In the second part after the break, we'll look at how to add more hosts and services running on them, without defining each of them individually. Using inheritance and referring common concepts like variables, we can scale our monitoring infrastructure. We're also structuring the infrastructure by creating users and groups for hosts and services. Each time, we'll directly see the changes in Icingaweb2 and on the commandline.

Monitoring services on remote hosts is done via OpenSSH in a secure way. The monitoring host establishes an SSH connection to the remote systems, executes the configured service checks, and delivers the result back to the monitoring host. That way, system administrators don't have to open up extra ports (on a firewall) since SSH is used on most Unix systems (and a growing number of Windows hosts) already. They can rely on OpenSSH's secure transport without having to worry about someone intercepting monitoring data which could be used as a preparation for an attack on these hosts. The tutorial walks through the necessary configuration steps for the monitoring host and the systems being monitored.

A couple of useful plugins are introduced to monitor BSD-specific services like outdated ports/packages. The tutorial closes with configuring and demonstrating how Icinga can automatically restart failed services. All configuration changes will be provided as a separate download to follow along. All necessary steps to get started with Icinga are being explained, beginning with the installation and configuration.

The tutorial is intended for beginners that have little to no prior experience with Icinga or Nagios. Basic knowledge of system administration tasks is required (installing software, editing files, switching users, changing ownership and permission on files and directories, network configuration, etc). Participants can use their own laptops to run the examples.

Benedict Reuschling joined the FreeBSD project in 2009. After receiving his full documentation commit bit in 2010, he actively began mentoring other people to become FreeBSD committers over the years. He joined the FreeBSD Foundation in 2015, where he is currently serving as vice-president. Benedict has a Master of Science degree in Computer Science. He is the system administrator for the big data cluster of the computer science department at the University of Applied Sciences, Darmstadt, Germany. Benedict is regularly teaching a UNIX for software developers class there and gives talks and tutorials at Unix/BSD conferences around the world.

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.

Virtualization tutorial, doesn't require previous knowledge of Xen or virtualization.

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.

Capsicum is a lightweight OS capability and sandbox framework in the FreeBSD operating system implementing a hybrid capability system model.

Capsicum continues to develop, however at a very slow pace. This framework is considered rather complicated. The goal of this tutorial is to make Capsicum more accessible for developers.

The first part is the introduction to the capability systems. We will discuss the limitations of the process in Capsicum. The role of the file descriptors will be discussed in this part as well with capability rights.

The second part is a short introduction to libnv which is a generic purpose container. libnv was designed as an IPC to use with sandboxed applications. For example it is used internally in libcasper.

The third part is the introduction to the extension of Capsicum in the FreeBSD.

The fourth and last part of the tutorial will be the practical part in which participants will sandbox an application in tree steps:

• using idealization phase,
• using a forked process to communicate with the original one,
• using Capser as a generic way of doing it.

Knowledge: C language

The requirement is to have a FreeBSD HEAD VM or PC.

Mariusz Zaborski is a QA and developer manager at Fudo Security.

At Fudo Security, Mariusz is developing a solution to monitor, record and control traffic in an IT infrastructure - the best PAM solution in the world.

He has been a proud owner of the FreeBSD commit bit since 2015. Mariusz main work in this project is focused, but not limited to, creating infrastructure around Capsicum, a process sandboxing technique based on capabilitie.

Mariusz's main areas of interest are OS security and low-level programming. In 2018 Mariusz organized the Polish BSD User Group. In his free time, he enjoys blogging (http://oshogbo.vexillium.org).

• Testing introduction

  Why do we write tests: What's in it for sysadmins? What's in it for developers? What is a good test?

• Introduction to ATF and Kyua

  Introduce the tools used for automated tests in FreeBSD, as well an guide in where to find the tests, how to run them and how to view results.

• Writing a very simple test for a very simple tool

  This serves as a hands-on exercise in using ATF to build tests.

• Introduction to VNET

  What is VNET, and why is it an important tool?

• Writing a simple network test

  Build on the previous exercise to write a test case for a networking subsystem.

  We'll pick an example subsystem (like carp, pf or ipfw) and write a simple test for it.

The goal of the tutorial is to set attendees on the road towards writing tests for FreeBSD, allowing them to test their own tools and/or produce test cases others can use to debug problems.

Attendees should have basic shell scripting skills, and a solid understanding of networking concepts. Please bring a FreeBSD 12.0 (or CURRENT) laptop or virtual machine with a FreeBSD source tree installed, as well as the following packages installed:

• kyua
• scapy

Alternatively, attendees may download the prepared VM from: https://www.sigsegv.be/files/Automated%20Testing.ova.xz

Kristof Provost is a freelance embedded software engineer specialising in network and video applications. He's a FreeBSD committer, maintainer of the pf firewall in FreeBSD and a board member of the EuroBSDCon foundation.

Kristof has an unfortunate tendency to stumble into uClibc bugs, and a burning hatred for FTP. Do not talk to him about IPv6 fragmentation.

Ports are the basis of which FreeBSD third party packages are created, and also used as a package system on FreeBSD. Working with ports, either maintaining existing ports or creating new ones, is a great way to get started contributing to FreeBSD and to get more involved in the community and the project. It is also a way to create easy to distribute packages for company internal software on your FreeBSD systems.

Poudriere is the tool used to build the official FreeBSD packages (for installation with pkg) and can also be used to build your own package sets for distribution in your local IT environment. It doubles as the tool used by porters to test the build and packaging of a port. It utilities FreeBSD jails and ZFS to make it possible to build ports for different FreeBSD versions and architectures, and to always have a clean environment when building a port.

This tutorial is divided into three parts. First, you will learn about Poudriere. We will walk through how to set up your own Poudriere environment and set up a jail to build in and a ports tree managed by Poudriere to build from. I will show the most common Poudriere commands and operations, their options and how they work. This will give you an understanding of Poudriere and how you can use it to build packages and test your own ports.

From there, we will move on to creating our own ports. We will talk about the ports tree and how it is structured and the various make commands used in the ports tree. We will then walk through the various files and pieces that makes up a port. Using real world examples I will show the basic building blocks of a port, and what they do. With this knowledge, we will create our own port of a simple example program.

The last part will detail how to use Poudriere to test our new port to make sure it builds and packages correctly. I will give a quick demonstration of portlint, a tool used to ensure that ports follows style guidelines. After that, we will use the Poudriere environment set up earlier to test that the port we just created builds and packages correctly. We will walk though some common errors and how to fix them.

This tutorial is aimed at anyone who want to learn the basics about FreeBSD ports system, and how to create and maintain a port. It is also aimed at anyone who want to use poudriere totest ports, and to build their own packages for distribution and installation. This can be used tocreate and distribute packages of internal tools at your work, or to help out with ports and packages in FreeBSD.

No previous knowledge of the Ports system or programming is needed, but some familiarity with FreeBSD and the command line is expected, as well as knowledge about how to edit files.

Niclas Zeising is an IT consultant based in Stockholm, Sweden, specializing in systems administration, IT operations, and IT security. He has been involved in the FreeBSD project for over a decade and has been a FreeBSD committer since 2012. Most notably, he's involved in the FreeBSD port of the xorg graphical environment and related software, working to improve the FreeBSD desktop experience as part of the Graphics Team. Niclas is also one of the organizers of the BSD Users Stockholm Meetup.

Yes, his laptop runs FreeBSD.

DRM (Direct Rendering Manager) is today standard for applications like a display server, to talk the the graphical hardware present on a computer or System On a Chip (SoC). It consist of a kernel side API and a userland part (via IOCTLs) that application can use to talk the GPU or configure the display modes (resolution, refresh rates etc ...). While support for X86 devices (intel or amd) are now correct on FreeBSD, arm and arm64 hardware support is still lacking. The only DRM driver is for Tegra based SoC, other hardware either have basic framebuffer support (like the RaspberryPi family) or will require the bootloader to have framebuffer support and will use it via EFI Graphic OutPut Protocol. While framebuffer might be enough for some use, having a DRM driver brings a lots of possibility, 2D acceleration, changing resolution, hotpluging another monitor etc ? And it is also mandatory if we want to support the 3D chip or the Video decoder usualy present on arm/arm64 SoCs. In this paper the author will describe the DRM subsystem and the anatomy of a modern DRM driver, based on his work on the Allwinner Display Engine 2 present in many SoC of this semiconductor company.

FreeBSD ARM and ARM64 kernel hacker. Single Board Computer collector. Emmanuel loves to learn new things and writing drivers for arm and arm64 boards.

Return Oriented Programming (ROP) is a common exploitation technique that reuses existing code fragments (gadgets) to construct shellcode in a compromised program. Recent changes in OpenBSD's compiler have started to reduce the number of gadgets in x86 and arm64 binaries, with the aim of making ROP exploitation more difficult or impossible. This paper will cover how ROP gadgets emerge from legitimate code, how OpenBSD's compiler removes these gadgets, and the effects on performance, code size, and ROP tool capabilities. We find that it is possible to meaningfully reduce the number of ROP gadgets in programs, and to effectively hinder ROP tool capabilities.

Todd Mortimer is a public servant from Ottawa, Canada, where he works in computer network defence. He has a background in penetration testing and Capture the Flag competition, and holds OSCP and OSCE certifications. Todd holds a BSc and MSc in Computing Science from the Universty of Alberta, where he worked on wireless medium access control protocols. He joined the OpenBSD project in 2017 and has been working on compiler-based exploit mitigations.

IBM POWER processors are 64-bit CPU’s designed primarily for server market. With POWER9, there has been renewed interest in them, due to the use of open-source firmware and focus on security and control of the hardware. There are also new desktop boards with POWER9. Because of that, support for them has been recently greatly improved in FreeBSD with increased driver compatibility and more 3rd party software having available. For my project, I build the whole ports tree using Poudriere and fix the compilation errors I meet. In this paper, I specify challenges met during porting software to work on POWER processors on FreeBSD and show how most problems can be solved. FreeBSD on POWER architecture runs in big-endian variant only and uses old toolchain – with GCC 4.2 and binutils 2.17. This is why many problems are related to fixing bugs in big-endian variants of code and solving issues related to the old toolchain that the operating system uses.

Piotr Kubaj is a sysadmin from Poland with an interest in *BSD operating systems, open-source firmware (coreboot and OpenPOWER) and IBM POWER architecture. He is interested in improving desktop experience on POWER architecture and maintains several ports, mostly desktop-related.

We consider that Unix operating system should be built on fine granular small parts (packages) to improve the system maintenance. It is expected that it enables speedy security update, system update tracking in detail, easy replacement and rollback of specific parts. We have implemented and run a new service to distribute modular base system userland for NetBSD. We generate the least amount of modular base packages by using {\tt basepkg.sh}. It splits NetBSD daily binaries into 1000 over packages based on {\tt syspkgs} meta-data and ident comparison within the binaries. This scheme drastically reduces the processing time to realize operations within practical time. Our system have shown that granular update system and service can be implemented and operational under breakdown approach. NetBSD users can maintain NetBSD base system in more granular way with fine update history and build an arbitrary system from the NetBSD minimal installation.

Free Software developer and ex-IIJ engineer (network/infra engineer). I use mainly Perl and Shell programming languages. The author of mailing list driver fml4 (pkgsrc/mail/fml) , fml8 (pkgsrc/mail/fml) and deprecated floppy size NetBSD "fdgw" (pkgsrc/sysutils/fdgw). Our laboratory have developed and been running NetBSD modular userland packages . http://www.fml.org/ https://github.com/fmlorg

Request-response workloads are common in practice, including key value stores, RPC and other HTTP workloads. Performance of these workload is largely limited by system call and I/O overheads, because the application needs to process a large number of requests arriving at the different TCP connections at the same time (e.g., notified by kevent), issuing a pair of system calls (e.g., read() and write()) to each of them. Even worse, inside the kernel, it is difficult to perform I/O batching across multiple TCP connections. In this talk, we report how FreeBSD performance can be improved using PASTE that uses netmap(4) API atop and below the kernel TCP/IP implementation. We show that PASTE improves throughput and latency by a factor of two; In BSDCan 2018, we introduced concepts of PASTE but without meaningful performance improvements in FreeBSD. Finally, we discuss issues we are facing, for example, soupcall() that is not notified of empty-data mbufs that carry FINs. Implementation and installation documents are available at https://micchie.net/paste/.

Michio Honda is a senior researcher at NEC Labs Europe in Heidelberg. Before that, he was a software engineer at NetApp in Munich. He received his phd degree in 2012 at Keio University in Japan. He has worked on transport protocols, middleboxes, user- and kernel-space network stacks, software switch and most recently, network stack design for non-volatile main memory. He has published in venues including ACM IMC, HotNets, CCR, SOSR and SoCC, and USENIX NSDI and ATC. He received IRTF/ISOC Applied Networking Research Prize in 2011 for his IMC paper, and best paper award at ACM SOSR'15.

We will have an overview of the available features in FreeBSD and OpenBSD, and see what some key components of LLVM sanitisers has to offer.

French software engineer living in Ireland since 2012, contributing to various open source projects from php to couple of video games. Had been interviewed by BSD Now (oct 2017) and EuroBSDCon 2018.

Operators of computer systems need to be aware of the state of their systems. As systems and networks become more intricate, the need for this information increases. This increase in complexity also leads to an increase in failure modes, often creating modes unique to the environment. This means that any monitoring setup must be as unique as the environment it operates on if it is going to be of use. As a result, it is frequently not possible to simply run an off-the-shelf solution, and an understanding of the principles behind monitoring systems must be applied to the implementation of your solution. This paper will cover many of the basic areas for monitoring, and how they can be applied to FreeBSD systems.

I am a FreeBSD system administrator working at ScaleEngine in Hamilton, Canada. I oversee a fleet of over 100 globally distributed servers and perform day to day management of the ScaleEngine video streaming CDN.

Intel HAXM (Hardware Accelerated Execution Manager) is a hypervisor that works as a loadable kernel module in multiple kernel environments. HAXM uses the Intel Virtualization Technology (VTx) and thus requires an Intel hardware architecture. A hypervisor (on a so called host machine) is a piece of software or hardware (sometimes both) that can create and run a virtual machine (called a guest machine). Usage of virtual machines reduces the need for using each software or product on dedicated hardware and can fully isolate it from the environment, which makes it suitable for data migration, reduction of costs of running multiple instances of guest machines on a host machine.

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.

The author describes existing procedures, tools, and ongoing development to improve the process of updating appliances, remote systems, and individual computers using ZFS. This paper describes a mechanism for replacing the operating system image with a newer image in a safe and atomic fashion. This system allows for fail-safe unattended upgrades of remote appliances and machines with a built in automatic recovery mechanism in the event of failure. Current and planned enhancements to 'poudriere image' are described as well as improvements to support tools including bectl and zfsbootcfg.

Allan is a FreeBSD Developer and an elected member of the FreeBSD Core Team, an OpenZFS Developer, and co-author of "FreeBSD Mastery: ZFS" and "FreeBSD Mastery: Advanced ZFS". Allan is the co-founder and VP of Engineering at Klara Inc., a global FreeBSD professional and enterprise services shop. He also hosts the weekly BSDNow.tv video podcast.

Traditionally associated with low-power, mobile computing, Arm is now seeking to enter the PC and the server markets. Virtualization is especially used in these areas, and current hypervisors rely on various hardware features to achieve efficient virtualization. To this end, the Armv8 architecture introduces a series of hardware mechanisms to reduce or eliminate some of the overhead associated with running virtual machines. Modern computers rely on hardware interrupts to communicate with peripherals, and this aspect of virtualization has seen a series of architectural optimizations from Arm. We will present our experience emulating the Generic Interrupt Controller version 3, the interrupt controller designed by Arm. We have used a mix of virtualization techniques: trap-and-emulate for the memory-mapped regions of the controller, which are accessed less frequently, and hardware accelerated virtualization where possible. To validate our approach, we have created a virtualized timer which is used to deliver timer interrupts to the virtual machines. Timers are essential for modern operating systems, and the virtualized timer is an abstraction over the Arm architectural timer, the Generic Timer. As with the interrupt controller, we have taken special care to take advantage of the available hardware mechanisms to reduce the cost of virtualization. The end result is a fully functioning hypervisor which is able to create, run and destroy virtual machines on Armv8.0-A and later processors.

Alexandru Elisei has a Bachelor's Degree in Computer Science from University Politehnica of Bucharest. He is very passionate about computers and open source software. Alexandru Elisei has made contributions to various open source projects, like FreeBSD, Gentoo, KVM-unit-tests and Moodle. He has also taken part in Google Summer of Code as a student developer.

Latrobe Community Health Service (LCHS) is a Not for Profit (NFP)/Non-Government Organisation (NGO) in Victoria, Australia. By 2018, the organisation had grown to 51 offices across the State of Victoria with over 1,000 employees. All LCHS infrastructure is designed and managed in-house without the use of largescale cloud infrastructure. Since 2015, BSD Unix has been used for various workloads within the organisation, with application instances interchanging between BSD distributions where it was deemed that one type was stronger than another at specific roles in the LCHS environment. LCHS is operating system distribution and technology-agnostic and prefer both FreeBSD and OpenBSD where either one and/or its associated base tools are most suitable. This paper outlines the various design considerations and configurations of OpenBSD and FreeBSD in multiple roles in our organisation.

Jason has over 23 years of IT industry experience in a vast range of disciplines and is currently the ICT Senior Security Lead at Latrobe Community Health Service (Victoria, Australia). Discovering Linux and Open Source in the mid 90's, then being introduced to OpenBSD in 2000, Jason has used these tools to solve various problems in organisations that cover different industries.

As more complex tasks are delegated to distributed servers, virtual machine hypervisors need to adapt and provide features that allow redundancy and load balancing. One such mechanism is the virtual machine save and restore through system snapshots. A snapshot should allow the complete restoration of the state that the virtual machine was in when the snapshot was created. Since the snapshot should encapsulate the entire state of the virtualized system, the guest system should not be able to differentiate between the moment a snapshot was created and the moment when the system was restored, regardless of how much real time has passed between the two events. This paper will present how the time management and block devices are saved and restored for bhyve, FreeBSD's virtual machine hypervisor.

My name is Darius Mihai. I am a second year Master's student at University POLITEHNICA of Bucharest in the field of Security of Complex Networks. I began my work on FreeBSD virtualization on ARM systems in March 2017 as part of my Bachelor Diploma project, and continued it until summer 2018 by extending support for VirtIO devices and powering a Linux guest on an ARM system. Starting August 2018 I've been working on improving support for bhyve snapshots on amd64 systems, by improving snapshot support for frame buffer, xHCI, e1000, timers and block devices.

When talking about servers and clouds, live migration is one of the most powerful tools that can be used to manage resources that are abstracted by virtual machines due to its small downtime. bhyve, FreeBSD's hypervisor, does not have a live migration feature implemented yet, even though it is a very useful feature for a hypervisor. This paper presents two approaches for implementing a live migration feature for bhyve that use the FreeBSD's virtual memory subsystem. The first one uses a Copy-on-Write mechanism that cannot be implemented due to bhyve memory layout, and the second one uses a dirty page detection mechanism.

My name is Elena Mihailescu. I am currently pursuing a Master's degree in Security of Complex Network at The Faculty of Automatic Control and Computer Science, University POLITEHNICA of Bucharest. My domain of interests includes operating systems internals and computer security. I have started working on FreeBSD virtualization in September 2017 when I began implementing a Save and Restore feature for bhyve for AMD CPUs.

The container-based virtualization, that multiplexes and isolates computing resource and name space which operating system (OS) provides for each process group of application, has been recently attracted. We focus on container migration among machines since it is one of the most important technology for realizing load balancing and increasing availability in cloud computing, that is a major application of the virtualization. Although FreeBSD VPS has already implemented one kind of migratable containers in FreeBSD, it is not enough in terms of resource limitation, compared to Linux one. This paper shows a novel implementation that how resource limitation and isolation close to that of Linux can be realized for FreeBSD containers. We also explain how processes, which could have sessions of file open and network connection, running in a FreeBSD container can be checkpointed and then they can be restored in another container. This implementation bases on runC which is one of standard container runtime and CRIU which is a major process migration tool in Linux.

Keeping track of time is an invaluable resource in modern software systems. The vast majority of existing CPUs posses various clocks and timers in order to accommodate time related mechanisms required by software. These same needs apply to virtualized environments, where the guest operating system uses time based events. To this end, a virtualized timer is required. This research project describes implementing such a timer in FreeBSD for the ARMv7 architecture.

My name is Mihai Carabas and I'm a assistant profesor at University POLITEHNICA of Bucharest in the domains like computer architecture and operating systems. I've contributed over the last five years in FreeBSD and DragonFlyBSD virtualization code. I've started working on BSD systems four years ago, on DragonFly BSD, tweaking its scheduler to be SMT (or HT) aware. In the next year I've implemented hardware nested page table support (EPT for Intel) for the DragonFly BSD vkernels eliminating the need of shadow page tables. In 2014 I've worked on a bhyve project where I've tried to minimize the impact of instruction emulation by caching the emulated instructions. Thus, at further usage, we use the hot cache instead of fetch-and-decode the faulted instruction again (the work has been presented during AsiaBSDCon 2015). In 2015 I've started working on porting the bhyve hypervisor on ARM-based platforms. I had to write from scratch the low-level context switch code and adapt it to a Type-2 hypervisor: ARM, by its design, ensures support for Type-1 hypervisors (a hypervisor that runs without a host OS). bhyve is written to be part of the FreeBSD and use its management features and thus its a Type-2 hypervisor. Another problem was to fork the current bhyve code base and reuse it with minor modifications for ARM (basically to preserve the same API - in the near future to be able to create a generic code-base for bhyve and only the context switch code to reside in the machine-dependant code). Until now I've manage to run a virtual machine on top of the bhyve hypervisor using FastModels simulation platform. There is work in progress at the virtualization of the interrupts to have a fully functional GuestOS. From 2014 in parallel with the work at bhyve I've promoted bhyve in my University and coordinated students to do bhyve-related projects. The current main projects I'm coordinating are: - save/restore and live migration features for x86_64 bhyve.

Contemporary Unix, defined as the sum of open source BSD Unix projects, Illumos distributions and GNU/Linux distributions, plus the OpenZFS cross-platform file system, can attribute their success to the collaborative work of like-minded academic, commercial, and volunteer developers around the world. Governed by a mix of licenses, best practices, community norms, and personal passion, open source projects like modern Unix operating systems and OpenZFS largely lack centralized Quality Engineering institutions, deferring Quality Engineering and Quality Control responsibilities to participating developers and the end user. This arrangement promises the widest-possible array of regression and performance testing tools, loads, and procedures, at the expense of providing any guarantees, true to the disclaimers of the licenses under which these projects are distributed. This paper will examine how “parallel, multi-axis” testing, defined as testing multiple software versions, operating systems, “options”, compilers, and architectures, or axes, in parallel, will improve the identification and isolation of reliability and performance regressions.

Michael has used BSD Unix systems for over 20 years and has organized open source events and projects around the world for over a decade with a focus on virtualization. Michael provides FreeNAS and FreeBSD training, support and marketing services at Gainframe, based in Portland, Oregon.

In a world where cloud computing and cloud infrastructures have become a mainstay, virtualization technologies have enabled a secure way to share resources with different users. A snapshoting mechanism is of great use in the area of virtualization, as it enables the backup of virtual machines, or the creation of templates for machine state replication. These virtual machines have many different virtual devices connected to them that need to have their state saved and restored for a system to be truly useful; examples include block devices, USB devices, or system time. For block I/O a virtual machine may use different types of files depending on its use case. This leads to a greater flexibility in terms of features; for example, one can use a file type that enables saving the state of the hard disk in order to be used later, or as a backup. Hypervisors like VirtualBox, VMWare and Hyper-V already have support for multiple disk file formats. This paper will present a way to implement support for the devices mentioned above, and fill readers in on the procedure of saving device states.

My name is Sergiu Weisz. I am a first year Master's student at University POLITEHNICA of Bucharest, in the field of Advanced Systems Security. I began work on the FreeBSD virtualization in August 2018 as part of my Master's research project. I have worked on the checkpoint functionality implemented by the FreeBSD-UPB team, which is now in the review phase. I have began work on the current project, upstreaming libvdsk and implementing QCOW2 support in bhyve, in December 2018. I have a great interest in kernel development, and in general systems related subjects. I'm also system administration enthisiast, and I teach systems-related labs from the Bachelor programme's curriculum.

FreeBSD that can be run on a small target such as a router using a build system called ZRouter It is building. I tried to explore the online update method of flash with these modules.

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.

Go is a programming language written in itself. It has its own linker and assembly syntax, and doesn't use calls from libc. To port it to another architecture means to provide a lot of syscall functionality normally present in libc. Simply copying the libc code is not possible, as Go also has its own calling convention. Debugging the new implementation on a young platform isn't the easiest, in the absence of full debugger support. I'll discuss what all those things mean, and the process of learning how to do it, despite limited prior experience.

Maya is a NetBSD developer since 2016, touching a wide variety of areas such as packaging, graphics support, porting of compilers.

The talk describes recent security additions in the FreeBSD boot process. It will describe describe UEFI Secure Boot support in the FreeBSD loader and kernel. The loader is now able to parse UEFI databases of keys and certificates which are used to verify a signed FreeBSD kernel binary, using BearSSL as the cryptographic backend. FreeBSD veriexec capability is employed to verify various userland binaries and conguration files - it was extended with the ability to use UEFI trust anchors as a base for veriexec manifest verification Additionally, TPM 2.0 devices are now supported in FreeBSD. They are most often referred to in the context of a measured boot, i.e. secure measurements and attestation of all images in the boot chain. The basic features of TPM will be described, as well as some caveats and shortcomings which may have contributed to its limited adoption. The presentation will include practical TPM use case, such as hardening Strongswan IPSec tunnels by performing IKE-related cryptographic operations within the TPM, using private keys which never leave the device.

Head of Engineering in Semihalf, src commiter since 2017. In FreeBSD I mostly take care of the Amazon ENA and Marvell SoCs support. I am the main contributor and maintainer of EDK2 port of the Marvell Armada SoCs. I also work a lot and contribute to Linux. In the past I had an opportunity to gain proficiency in a high-speed PCB design. Privately a father of 3 and huge fan of sports.

CPAchecker is a platform for software-verification created to be extensible by implementing an interface of configurable program analysis. It comes with various configurations for checking a program for correctness or to produce a counterexample after falsification.This paper displays the strengths and weaknesses of CPAchecker based on the key insights gained from the "Application of Software Verification to OpenBSD Network Modules". This is to provide a view on the applicability of formal verification on the OpenBSD source code with the goal of improving its quality.

Moritz Buhl has been an OpenBSD user since 5.3 and contributor since 6.3. He is currently finishing his Bachelor's degree in computer science at the Ludwig-Maximilians University Munich. Since 2018 he has been working as a working student for software development at genua GmbH near Munich.