Embedded Ethics
Patricia Aas
Patricia is a programmer who has worked mostly in C++ and Java. She has spent her career continuously delivering from the same code-base to a large user base, from working on two browsers (Opera and Vivaldi), to working on embedded telepresence endpoints for Cisco. She is focused on the maintainability and flexibility of software architecture, and how to extend it to provide cutting edge user experiences.
Her focus on the end users has led her work more and more toward privacy and security, and she has recently started her own company, TurtleSec, hoping to contribute positively to the infosec and C++ communities. She is also involved in the #include
Paul Vixie talks about DNS over HTTPS
Paul Vixie
Paul Vixie was responsible for BIND from 1989 to 1999, and is the author of a dozen or so IETF RFC documents about DNS. He also started the first anti-spam company (MAPS) where he co-invented the DNS RBL (Realtime Blackhole List), and was the founder and later president of the first U.S.-based commercial Internet Exchange (PAIX). Today he serves as CEO of Farsight Security, home of the Security Information Exchange (SIE) and the world’s leading Passive DNS database (DNSDB). He wrote the Cron software used on all UNIX-type computers today. He is also co-inventor of the DNS Response Rate Limiting (RRL) and Response Policy Zone (RPZ) feature-sets now in wide use to protect the operational Internet Domain Name System against online attacks. He received his Ph.D. from Keio University in 2011, and was inducted into the Internet Hall of Fame in 2014.
Improving modularity of NetBSD’s compat code
This presentation will describe recent changes to the NetBSD code that provides compatability with earlier versions. We will discuss some of the short-comings of the NetBSD-8 implementation, such as the lack of granularity of loadable modules and inability to include all of the compatability code in the loadable modules. We will describe the approaches taken to resolve these issues, and some of the infrastructure changes needed to accomodate them, with detailed focus on the mechanisms which ensure that code being executed does not get unloaded. Finally, we will discuss the current state of the implementation, along with a list of things that remain to be done.
Paul Goyette
Paul Goyette has been a software developer for almost 50 years, with more than 25 years involvement with NetBSD and more than 11 years as an official NetBSD developer. His current focus in on the development and use of loadable kernel modules; previously he focused on NetBSD’s sysmon(4) subsystem, and was an early and major proponent of the continuous build-and-test system. He has made numerous contributions throughout the NetBSD kernel and user-land, and at one time was known for the “SLOTMAN” kernels which enabled use of non-monochrome X11 on the mac68k port of NetBSD-0.9!
Originally a product of the US Northeast, he spent most of his adult life in the San Francisco Bay Area before retiring to the Philippines. He has just recently returned to the US, now residing in Springfield, Oregon. This is his first formal technical presentation in any venue.
CheriABI: Hardware enforced memory safety for FreeBSD
Memory safety bugs such as buffer overflows are an ongoing source of security vulnerabilities. CheriABI is a new process model for FreeBSD on the Capability Hardware Enhanced RISC Instructions (CHERI) hardware platform which eliminates the vast majority of buffer overflows and significantly increases the difficulty of control-flow attacks such as return-oriented programming.
Our protections cover programs, the C run-time environment including the dynamic linker, and kernel access to user memory. We have ported virtually all of the FreeBSD user space this platform demonstrating that memory safety can be fitted to existing C software.
Brooks Davis
Brooks Davis is a Senior Software Engineer 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 2019 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. When not computing, he enjoys cooking, brewing, gardening, woodworking, blacksmithing, and hiking.
The OpenBSD hypervisor in the wild, a short story.
OpenBSD Amsterdam started in the summer of 2018 after a poll on Twitter as an idea to start testing with vmm(4)/vmd(8). Mostly to see how far we could take it and more importantly to give back to the project. Little did we know where it would take us.
During this talk I will outline how it all started, how it’s build, how we operate the platform and what speedbumps we encountered.
We are a big proponent of using as much out of base as possible and it has influenced our design choices a lot. These choices will be highlighted when discussing how the platform is build and how it’s operated.
Mischa Peters
Mischa Peters is a long term BSD user, starting with FreeBSD 2.x and later OpenBSD as well. He is operating a hosting and co-location company out of Amsterdam The Netherlands, currently focused on providing services on top of OpenBSD and FreeBSD. The OpenBSD Amsterdam project is a good example of it. For his $dayjob he is leading a team of System/Solutions Engineers for a security startup.
Fuzzing Filesystems on NetBSD via AFL+KCOV
Filesystems are one of the most important parts of OS. Because they are responsible for storing user data, any software bug can potentially cause damage and data corruption. So from OS users perspective, data needs to be safe and bulletproof. Any data corruption may imminently cause users to switch to other software stacks. Because of that part of the NetBSD, the community decided to spend more effort on hardening FSes. For the last few years, NetBSD became strong with new security features in the BSD world as Sanitizers or Fuzzers. Now this work is being used to finding and fixing different FS bugs.
Maciej Grochowski
System Engineer experienced at work with various Operating Systems: from Solaris, Linux to FreeBSD. Currently helping NetBSD. Interested in Storage and Filesystems, Fast and Low latency code, and modern kernel features. Ex. Intel, Veritas, NTT. At this moment developing infrastructure for Cloud Gaming at Playstation.
Improving security of FreeBSD with TPM 2.0 and Intel SGX
The talk describes the concepts behind TPM, together with a short introduction to Intel SGX.
TPM 2.0 devices are now supported in FreeBSD. They are most often referred to in the context of measured boot, i.e. secure measurements and attestation of all images in the boot chain. The TPM 2.0 specification defines versatile HSM devices which can also strengthen security of various other parts of your system. I will describe the basic features of TPM and mention some caveats and shortcomings which may have contributed to its limited adoption. The presentation will include practical TPM use cases such as hardening Strongswan IPSec tunnels by signing with the TPM and locking in secrets to a particular boot hash chain.
The second part will describe Intel SGX – a hardware based Trusted Execution Enviroment. (TEE) It will be started with describing basic concepts behind TEEs and SGX in particular. Next security advantages of using SGX will be discussed, as well as some of the vulnerabilities inherited from the past. The presentation will be concluded with a short report about SGX support in FreeBSD.
Kornel Dulęba
Jagiellonian University student and software developer working for Semihalf. He specializes in operating systems and security. He made multiple contributions to FreeBSD project including writing TPM 2.0 driver from scratch.
Modernizing relayd and the road to HTTP/2
This talk is about my recent work to modernize relayd, to fix long-standing issues and limitations, and about the road to HTTP/2 in OpenBSD’s web stack.
relayd’s HTTP support dates back to early 2007, about three months after it was imported into OpenBSD for the first time. It was a necessary feature to complement relayd’s pf-based redirections with layer 7 load balancing for cookie-awareness, SSL acceleration, and basic header or URL filtering. The daemon has been improved, renamed, hardened, and widely deployed over the years.
Meanwhile, the web has changed a lot. While relayd is still a very useful tool, it had to get modernized to stay relevant. OpenBSD’s Claudio Jeker had updated the TLS support in 2017, and I added missing features such as TLS SNI and OCSP this year. Furthermore, I improved the protocol filters to offer greater flexibility when relaying HTTP traffic and I finally fixed a persistency bug that was a big show stopper for such filters.
But the most important step forward is HTTP/2. While the IETF was about to finalize the QUIC- and UDP-based HTTP/3, relayd and httpd were still based on the dated and text-based HTTP/1.1. I started my road to add HTTP/2 support to relayd and subsequently to httpd. This talk addresses the ongoing work of the implementation, awesome HPACK header compression, and challenges with HTTP/2 states and multiplexing.
Reyk Floeter
Reyk is an OpenBSD hacker who now lives in beautiful Zurich, Switzerland. He has worked as a network security consultant, lead software engineer, and founder of multiple startups such as Esdenera and .vantronix. For more than 15 years, he gained experience in creating enterprise-class products based on OpenBSD. Reyk is the author of the popular relayd load balancer and contributed various OpenBSD features, fixes, networking drivers and daemons since 2004, like OpenBSD’s ath, trunk (a.k.a. lagg), vic, hostapd, relayd, snmpd, iked, httpd, and significant parts of vmd.
Fuzzing the kernel
Modern C compilers include support for tools to help find bugs in code. These tools, the sanitizers, add instrumentation to the generated code that can be compiled into the kernel to help the kernel developers. In early 2018 I became interested in using these in the FreeBSD kernel to assist bug finding and debugging.
This talk will discuss the current state of kernel sanitizers on FreeBSD. This will include the kernel coverage sanitizer that can be used with fuzzers, the undefined behaviour sanitizer to warn when code relies on undefined behaviour, and the address sanitizer to detect out of bounds accesses. It will also discuss future work to port new sanitizers and the use hardware based acceleration.
The main fuzzer to use these sanitizers is the syzkaller fuzzer from Google. I will talk about my experiences using this, bugs it has found, and future work to port other fuzzers to work with the kernel.
Andrew Turner
Andrew is a FreeBSD committer known for porting FreeBSD to the 64 bit Arm architecture. Recently he has worked on improving the kernel code quality by enabling kernel fuzzing through compiler sanitizers.
Andrew works as a Freelance Software Engineer and a Research Associate at the University of Cambridge working on the CHERI project. He is interested in using existing and novel hardware features to help improve code quality and security.
Bhyve guests with hardware accelerated graphics
FreeBSD is not only a great platform for server, it is also a brilliant choice for workstation and desktop. However, there’re still a lot of applications that are not *BSD aware. The solution is Bhyve, the BSD Hypervisor which allows you to run these applications in virtual machines on top of FreeBSD. You also want these fancy, graphically intensive desktop applications to run smooth! Therefore a Smart BSD user like you automatically think about GPU passthrough…. and you quickly realise it’s not support as listed in the bhyve Wiki.
*Or is it? *
If you are someone like me who run FreeBSD-CURRENT on your primary workstation, you may have encountered the following problems:
- Your new shinny RTX graphics card won’t work in CURRENT because the official Nvidia driver only support up to 12-STABLE and the driver from ports only support up to 1080Ti.
- You need to run some applications in a Bhyve Virtual machines that’s graphically intensive
- You want to accelerate OpenGL on *nix VM.
This talk will introduce you some tricks to enable usable GPU passthrough and other tricks to enable hardware acceleration for bhyve guests.
Yan Ka Chiu
Michael is a person who may or may not exists who become a FreeBSD user |Z_2[x]/
Game of Trees
Stefan Sperling
Stefan Sperling works as a freelance open source developer and consultant and is based in Berlin. Stefan has been involved in the OpenBSD project for a decade, and he is also one of the main contributors to the Apache Subversion version control system.
7th Edition Unix at 40
This year marks the 40th anniversary of the 7th Edition of Unix and 50 years since Thompson and Ritchie started writing Unix. In honor of these milestones, the author set about to recreate a historic commercial port of Unix to 8088 (Venix/86). This talk explores how V7 Unix has many children; how Unix has changed since the 7th Edition days; chronicles the creation of a V7 emulator needed to run the original compiler on fast hardware; and explores how to recreate sources to systems that have diverted from the now-public sources to recreate many of the binaries from the Venix/86 distribution. A better understanding of Unix’s past helps with understanding BSD systems today.
Ken and Dennis started to create Unix 50 years ago, about the time the United States was landing on the moon. It grew inside of Bell Labs for a decade, culminating in the 7th Edition of Unix, which spawned many children including System V, BSD, and many commercial Unixes. From this base, Unix was ported to many machines. One of these ports was Venix/86 which ran on 8086 and 8088 machines (and later 80286). The author’s first computer was the DEC Rainbow 100, a now-obscure also-ran released about the same time as the IBM-PC. The author searched for many years to find a copy of Venix/86R for the Rainbow, only to be disappointed until recently when a copy resurfaced which he helped recover. Noting the system was a commercial derivative of V7, the author set about to reconstruct the sources, as far as possible. The old hardware ran hundreds of times slower than modern hardware, so the author created a Venix/86 emulator to run the old compiler on modern hardware. The emulator is fairly advanced, and many of the sources have so-far been recovered. This talk will explore a number of topics: a history of Unix; the surprising things that were in V7 unix; the things we take for granted today that were missing; a discussion about creating a Venix/86 emulator and reverse engineering ABIs; and early results from the recreation efforts. Come for the history, stay for the riveting discussions of syscalls, calling conventions and binary emulation! This will be the perfect opportunity to understand where BSD came from; the debt we owe to Bell Labs; and learn from a simpler system to better understand today’s BSD systems.
Why I prefer thick jails over thin jails
Jails have a long history on FreeBSD. ezjail came along and used a shared basejail for all the jails. Upgrade that jail, and you’ve upgraded all the jails. It was wonderful, convenient, and fast.
After a few upgrades between major versions, the author discovered he hadn’t been runing mergemaster on all those jails for all those years. Useful new features were unavailable, such as include on newsyslog.conf(5). Much time was spent doing mergemaster on many jails.
Furthermore, if you upgraded the basejail, you really need to upgrade all the jails or you’d get stuff failing to run properly.
There is more than one jail manager on FreeBSD. The author has also used iocage and likes each of for different reasons. When he decided to convert a server from ezjail to iocage, the existing script did not work, so he wrote a new one. He has since used it to convert two servers and has plans for two more.
Now, the upgrades between major versions are relatively eaiser, but can be managed on a need-to-do basis. The host can be upgraded one day, and the jails left for weeks, or in the author’s case, months later.
Learn from his mistakes, come see thin-to-thick.
This talk will cover:
- short introduction to jails
- brief overview of ezjail and iocage
- why convert from thin to thick
- the problems solved by the new script
- why thick is not for you
- when thin is better
- monitoring tips to track vulns in your jails
- why you should never use jail managers
- why you should always a jail manager
- why etcmerge is something you should know about
After hearing this talk, you will know how to convert a thick jail to a thin jail and wonder why you never did this before. Your system upgrades will be easier, and your jails will be more robust.
Dan Langille
Dan Langille first started with Unix-like operating systems sometime in the early 1980s. In 1998, he discovered FreeBSD on a near-daily basis after needing a firewall for his ADSL connection. From that start, he began several online journals, founded two highly successful open source conferences, and eventually turned his hobby into a profession.
Dan now works as a sysadmin for a widely-known infosec company and is frequently impressed by those he works with.
When not running conferences or working, Dan blogs about this activities. He wishes he did more mountain biking.
Visualization of Regression and Performance
Know when something went wrong
When you try a new software version, something may be wrong or slow. After updating OpenBSD you might see that something does not work as it used to be. To simplify debugging it is helpful to determine the point in time when the change was introduced and search for the relevant commit.
Making statements about performance is more difficult than for functional regressions. The requirements for measurements may change, new test programs are needed, test hardware is only available for a limited time. So it is not sufficient to store historic data on a daily basis. You want to change granularity or look back into the past.
For that purpose I have created a system that can create a performance history of the OpenBSD kernel. The kernel is compiled from certain CVS checkouts. That may sound easier than it is as the OpenBSD kernel is not self contained. It belongs to a base system, there may be incompatibilities with userland. The performance also depends on the compiler version that changes over an OpenBSD development cycle. My framework addresses this in an automated way.
An overview of all tests results is here: http://bluhm.genua.de/perform/results/perform.html
This is a follow up to my talk at BSDCan 2019. I will add new findings and conclusions which were detected during the last months.
Alexander Bluhm
Alexander Bluhm is an OpenBSD developer for more than 10 years. His main areas are the network stack and regression testing. With the latter also comes bug fixing in many parts of the system. He is working at genua GmbH, a company that builds firewalls and VPN gateways based on OpenBSD.
Porting the Robot Operating System (ROS) to FreeBSD
Robots are an exciting technology that is continually being researched and brought closer to the mainstream. Why should the BSDs be left out of this technology? The robot operating system (ROS) is a middleware solution for communicating between different robot and sensor nodes. It is also a collection of software mostly under a BSD or BSD-compatible license. Being open source, much of it can work on FreeBSD, but there are a few missing pieces. This talk will introduce ROS, talk a little about its past history with FreeBSD, describe the missing pieces to make it work on FreeBSD, document the porting process, and offer a starting point for how to integrate ROS into the ports system.
Trenton Schulz
| Trenton Schulz first encountered FreeBSD in 1997 when some fellow students in the computer lab were installing FreeBSD 2.2.2 over the Internet. He was so intrigued he brought his computer to the lab to get it installed as well. Later, he escaped to Norway and worked at Trolltech and helped port Qt’s virtual frame buffer to work on FreeBSD before moving onto working on Qt/Mac. After helping with a Cocoa port of Qt, he began a career in research and is currently finishing his Ph.D. in human-robot interaction at the University of Oslo. |
OpenBSD: add VMM to ‘packer’
The sysadmin view of virtualization usually starts at a hypervisor running some kind of “image”. Packer is a framework to create such an image using various host and virtualized operating systems and adding some more bolts.
This talk shows the efforts and pitfalls of building a plugin for packer using the VMM framework on OpenBSD. Some details go down the rabbit hole (or reducing it) to provide a Go binary runnable as a plugin. For ease of installation, the ways how to package this as an OpenBSD ‘port’ are shown.
On top a bigger picture is provided on how to provide configurable OpenBSD images “at scale” by using the above accomplishments.
Philipp Buehler
Philipp uses Unix since mid 1990s and OpenBSD since 2000. Born and working in Germany mainly in Unix/Linux/BSD areas including ISP services and networking. Been an OpenBSD developer from 2002 to 2005, trying to cleanup and test pf(4). Co-founder of sysfive.com GmbH having the technical lead in designing and operating FOSS-based business plattforms.
Rust: Systems Programmers Can Have Nice Things
Rust is a new programming language, originally from Mozilla, that combines the safety and productivity of a high-level language with the performance and low-level control of a traditional systems language. Rust achieves this combination through clever and pragmatic programming language design — along with awesome tooling and libraries.
In this talk, I will dive into the features that make Rust the right choice for 21st-century systems programming. I will give a general introduction to the language and an overview of the Rust ecosystem. I will also walk through the process of developing Rust on BSD.
Arun Thomas
Arun Thomas is an operating systems researcher and an open source developer. He got his first taste of BSD in 2002.
Arun is a Principal Scientist at Draper Laboratory. At Draper, Arun leads the DARPA-funded SSITH/HOPE project, a research collaboration with the University of Pennsylvania, MIT, PSU, INRIA, Dover Microsystems, and Dornerworks to develop a hardware security architecture that enables flexible, verified policy enforcement on RISC-V. Recently, he has been exploring the use of Rust as a foundational technology for building secure systems. Arun has spoken about systems programming topics at ARM TechCon, the Embedded Systems Conference (ESC), BSDCan, EuroBSDcon, BSDTW, FOSDEM, Systems We Love, the RISC-V Workshop, and the Oxidize Embedded Rust Conference.
Kernel TLS and TLS hardware offload
TLS (Transport Layer Security) is a widely-deployed network protocol used for providing cryptographically proven security and authentication of TCP sessions. A kernel implementation of TLS will provide access to TLS hardware offload, ability to access unencrypted bytes of data in the kernel, and a reduction in copies to and from userspace by allowing the use of the sendfile(9) system call for TLS encrypted data.
This talk will start from explaining the basics of TLS protocol, using OpenSSL as an example, cover the advantages and motivation for kernel TLS (KTLS) and later will dive in to the implementation.
One of the major advantages of KTLS is the ability to offload TLS symmetric crypto processing to the network device. This talk will cover TLS hardware offload approaches, like TOE and inline TLS acceleration.
We will close with some performance numbers comparing OpenSSL, KTLS and hardware offloaded TLS with data taken from Netflix servers.
Slava Shwartsman
For the last years I have been working for Mellanox Technologies. My main focus is developing high performance network drivers for data centers and HPC costumers both for InfiniBand and Ethernet (RoCE). I took major part in maintaining Mellanox drivers in RHEL and RHEL-ALT. Also I took part in developing features for Linux kernel. For the last few years I’m one of the core maintainers of the Mellanox drivers and the InfiniBand subsystem in FreeBSD.
Some more general background – I have a B.Sc in Computer Science and CCNA. Before joining Mellanox, I served as a computer networks instructor in the Israeli Defense Forces.
Drew Gallatin
Drew started working on FreeBSD at Duke in the 90s, and was one of the people behind the FreeBSD/alpha port. He worked on zero-copy TCP optimizations for FreeBSD and was sending data at over 1Gb/s before gigabit Ethernet was generally available. He spent a decade at Myricom, optimizing their drivers. After a brief hiatus at Google, he landed at Netflix, where he works on optimizing the FreeBSD kernel and network stack for content delivery. He worked on the optimizations to serve unencrypted Netflix traffic at 100Gb/s, and then on more optimizations to send encrypted traffic at 100Gb/s.
Wireless Fidelity with bwfm(4)
The Broadcom Wireless FullMAC chip has been one of the biggest hurdles in properly supporting Apple MacBooks in the recent years. But that has not been the only place where this chip has popped up. bwfm(4) is a new OpenBSD driver that supports these chips and was also ported to NetBSD. This talks gives an overview of the chip, an in-depth view into how one communicates with the chip on the three different supported busses, and the higher layer protocol that’s being run on top. It also shows issues properly combining the driver with the OpenBSD net80211 stack, which isn’t written to handle FullMACs. The talk also shows the Firmware and NVRAM distribution issues.
Patrick Wildt has been maintaining and improving the OpenBSD armv7 and arm64 subtree for several years, adding support for multiple SoCs and adding device tree support. Recently he wrote bwfm(4) to add support for the Broadcom FullMAC chips.
Patrick Wildt
Patrick Wildt works for genua, a company that builds OpenBSD based firewalls and VPN gateways. He has been an OpenBSD developer since 2012, where he takes care of the ARM subtree, writes device drivers to support new hardware, and occasionally updates the compiler infrastructure.
ZFS for newbies
Dan Langille thinks ZFS is the best thing to happen to filesystems since he stopped using floppy disks. ZFS can simplify so many things and lets you do things you could not do before. If you’re not using ZFS already, this entry-level talk will introduce you to the basics. Things we will cover include:
- a short history of the origins
- an overview of how ZFS works
- replacing a failed drive
- why you don’t want a RAID card
- scalability
- data integrity (detection of file corruption)
- why you’ll love snapshots
- sending of filesystems to remote servers
- creating a mirror
- how to create a ZFS array with multiple drives which can lose up to 3 drives without loss of data.
- mounting datasets anywhere in other datasets
- using zfs to save your current install before upgrading it
- simple recommendations for ZFS arrays
- why single drive ZFS is better than no ZFS
- no, you don’t need ECC
- quotas
- monitoring ZFS
This talk is designed to get you interested in ZFS and see the potential for making your your data safer and your sysadmin duties lighter. If you come away with half the enthusiasm for ZFS that Dan has, you’ll really enjoy ZFS and appreciate how much easier it makes every-day tasks.
Dan Langille
Dan Langille first started with Unix-like operating systems sometime in the early 1980s. In 1998, he discovered FreeBSD on a near-daily basis after needing a firewall for his ADSL connection. From that start, he began several online journals, founded two highly successful open source conferences, and eventually turned his hobby into a profession.
Dan now works as a sysadmin for a widely-known infosec company and is frequently impressed by those he works with.
When not running conferences or working, Dan blogs about this activities. He wishes he did more mountain biking.
NUMA Optimizations in the FreeBSD Network Stack
I will discuss optimizations to keep network connections and their resources local to NUMA domains. These changes include:
- Allocating NUMA local memory to back files sent via sendfile(9).
- Allocating NUMA local memory for Kernel TLS crypto buffers.
- Directing connections to TCP Pacers and kTLS workers bound to the local domain.
- Directing incoming connections to Nginx workers bound to the local domain via modifications to SO_REUSEPORT_LB listen sockets.
I will present data from real Netflix servers showing an improvement of almost 2x on AMD EPYC (85Gbs -> 165Gbs), and 1.3x on Intel Xeon (140Gb/s -> 180Gbs). I will present data from the Xeon system showing a 50% reduction in cross-domain traffic.
Drew Gallatin
Drew started working on FreeBSD at Duke in the 90s, and was one of the people behind the FreeBSD/alpha port. He worked on zero-copy TCP optimizations for FreeBSD and was sending data at over 1Gb/s before gigabit Ethernet was generally available. He spent a decade at Myricom, optimizing their drivers. After a brief hiatus at Google, he landed at Netflix, where he works on optimizing the FreeBSD kernel and network stack for content delivery. He worked on the optimizations to serve unencrypted Netflix traffic at 100Gb/s, and then on more optimizations to send encrypted traffic at 100Gb/s.
Advanced ports toolkit: near-perfect packing-list generation
The OpenBSD ports tree uses an unique approach.
Instead of ad-hoc scripts that manipulate textual information, we do have a semantic parser that creates objects for each element in the plist.
The last year saw a complete rewrite of the most complicated piece of machinery, namely update-plist.
There are lots of interesting challenges, specifically how to write a generic tool that will handle all the semantic annotations that currently figure in packing-lists with minimal special-casing:
- variables that expand to nothing for some flavors,
- ambiguous variable expansions,
- directories that may not exist for python2 ports,
- automatic dispatching to the right subpackage and fragment,
- shared libraries,
- smart file type handling for libraries, icon themes, etc
Before and after comparison shows a new tool that requires minimal human intervention (perfect packing-list re-generation in over 95% of the cases), where the old update-plist required hand-holding over half the time.
Marc Espie
Researcher/Teacher in development security at Epita.
Architect of the OpenBSD packages and ports system.
The future of OpenZFS and FreeBSD
Looking at the recent changes to the OpenZFS Project, and how FreeBSD will interact with the OpenZFS Project going forward.
This talk will discuss:
- How the OpenZFS project started
- How the OpenZFS project has changed over the last 5 years
- The introduction of the monthly ZFS Leadership Call
- New problems as ZFS has matured (needing to add a deprecation policy, etc)
- How the OpenZFS project is working to reduce the differences across platforms (command line switches, NFS differences)
- Interoperability improvements (feature flag ‘compatibility’ groups)
- New procedures to prevent divergence and coordinate development across platforms (reserving flags, wider discussion before names for features/flags are decided)
Then switch gears and cover FreeBSD specific issues:
- The switch to ZoL as upstream
- Why we are making the change
- What we get out of it
- How it is better for all of OpenZFS
And finally a status report:
- ZFS-on-Linux and ZFS-on-FreeBSD are now “OpenZFS”
- There is no LinuxKPI in ZFS (kill the FUD)
- What has OpenZFS done for me lately (new and upcoming features)
Allan Jude
- FreeBSD user (2001), doc (2014), and src (2015) committer. FreeBSD Core Team (2016-2020)
- Co-Author of “FreeBSD Mastery: ZFS” and “FreeBSD Mastery: Advanced ZFS” with Michael W. Lucas
- VP Engineering at Klara Inc (FreeBSD development and support services)
Sharing and Rotating Credentials in a Hostile Environment
Managing servers is hard, & managing server credentials is even harder.
Easier said than done, this talk covers one way of doing this, to handle typical passwords, long-running tokens for server daemons, one-time usage ssh keys for those pesky sys admins, and auto-rotation of tokens for application logins.
How many people have not rotated ssh keys, never changed root passwords and maybe, just maybe, put those things on sticky notes on your desktop?
Nobody, right? Nobody ever does that because it’s WRONG.
In today’s environment with untrustworthy cloud providers, and even more untrustworthy hardware vendors, it’s important that we keep a firm hand on our credentials. One of the easiest ways to do this is to hand out those tokens just before usage, and to expire them as soon as possible.
For users, this means automating the process of rotating keys, and to revoke them as soon as their session has completed.
For applications, this can often require a complex dance of managing layers of security, on top of software that was never expected to work in this way.
This talk will cover:
- what we tried to address
- what we did not
- tools we used
- practical lessons learned (please laugh at our mistakes)
- opportunities for further improvement
What’s in this for attendees?
If you’re familiar with ssh, have dealt with logins for common databases such as PostGres, MySQL, or webservers, then you should have no trouble understanding this talk.
If you are concerned about managing credentials for your end users, then this talk is for you. If you’re not concerned about managing credentials for your organisation, then you really need to come to this talk.
You’ll be able to apply much of the information in this talk to your organisation, but security is a complex arena and there is no forklift upgrade to make your pain go away.
Dave Cottlehuber
Dave has spent the last 2 decades trying to stay at least 1 step ahead of The Bad Actors on the internet, starting off with OpenBSD 2.8, and the last 7 years with FreeBSD since 9.3, where he has a ports commit bit, and a prediliction for obscure functional programming languages that align with his enjoyment of distributed systems, & power tools with very sharp edges.
- Professional Yak Herder, shaving BSD-coloured yaks since ~ 2000
- FreeBSD ports@ committer
- Ansible DevOops master
- Elixir & Erlang/OTP developer
- Building distributed systems with RabbitMQ and Apache CouchDB
- enjoys telemark skiing, and playing celtic folk music on the accordion and violin.
23 years of software side channel attacks
I will present a historical review of software side channel attacks, from Paul Kocher’s 1996 timing attacks against asymmetric cryptography to the latest microarchitectural vulnerabilities. While there have been too many attacks discovered to spend time describing every one, I will highlight attacks which were particularly novel or influential, explaining both the history of how attacks build on earlier work and some of the reasons behind the decisions which led to these attacks being possible.
No knowledge of cryptography will be assumed, but the audience may benefit from a basic understanding of CPU architecture (instructions, pipelining, caches, etc).
Colin Percival
Dr. Colin Percival has been a FreeBSD developer since 2004, and has served over the years as the project Security Officer, a Core Team member, and most recently as the maintainer of the FreeBSD/EC2 platform. He is also the founder of the Tarsnap online backup service.
On the rare occasions when he steps away from his laptop, he can be found playing violin in an amateur orchestra near to his home in Vancouver, Canada.
pkgbase: Are we there yet ???
pkgbase on FreeBSD is the method currently developed to handle base installation and update/upgrade with pkg(8). It was started by Baptiste Daroussin (bapt@) a few years ago and first presented in BSDCan 2015 (see https://www.bsdcan.org/2015/schedule/events/563.en.html). It was also planned to be included in 12.0-RELEASE but this didn’t happened.
I recently revive the work since I needed to create an appliance with an installer and an update system. Of course it didn’t work out of the box and I had a lots of issues, some known, some not known. We will see all the remaining issues when I started working on it, from config file to bsdinstall(8) support and multiple kernel installation. Since this is an ongoing effort all those issues will be hopefully resolved by the time this presentation is happening.
Emmanuel Vadot
FreeBSD kernel hacker and ARM board collector.
Unbound & FreeBSD: A true love story
This presentation describes how a well-planned engineering project for a DNS infrastructure running on a very big cell phone company had to deal with unexpected issues from external factors, and how they were overcome with the invaluable help of the DNS software Unbound, in conjunction with the FreeBSD operating system.
We will explore:
- Numbers and facts from the former DNS service that was running degraded
- Why a local economical crisis changed the plans of hardware/software to be installed by a vendor
- Why triggered the deployment of open source software on recycled hardware by in-house sysadmins
- And why lasted about 6 months without hassle until situation got back to ‘normal’ state.
In the talk we will also see different approaches done on a little physical hardware lab, with the invaluable help of stress testing/monitoring CLI tools, plus well-written documentation like Calomel’s website for doing fine tuning on both DNS software/OS.
Finally, conclusions and lessons learned are provided to have a starting point with a solid base and provide the necessary tools for new DNS projects.
Pablo Carboni
Pablo Carboni worked as Unix/DNS/Net Admin over the last 2 decades, specially with FreeBSD platforms, and latest times as DevOps. His main passions includes -but not limited to- DNS, *BSD, RFCs, low level protocols, and sometimes as unix developer too.
As an amateur developer (C language specially), he collaborated with Net-SNMP project by sending patches for multi-core CPU usage support under *BSD platforms.
FreeBSD and the absurdities of security compliance
Assume absurdity, embrace sanity. Welcome to The Blame Game.
The world of security compliance is defined by a few key players: The ones writing the requirements, the ones covering their asses, and the ones who’ll be blamed in the end. Since about 2008 we’ve been firmly placed in the latter category, and despite the obvious downsides it is, really, where we prefer to be.
Security requirements pertaining to the payment industry include the various PCI standards, card system specific requirements, national and regional laws, regulations and directives, and whatever else comes to the minds of the various players. While there is sanity to be found in some of them, there is also plenty of absurdity. It is this, above all, that leads us to use the term “The Blame Game” about it all.
We do pretty much everything with FreeBSD. From routers (bsdrp) and firewalls (pfSense) to application- and database servers, we’re running FreeBSD everywhere. The only closed-source software we employ are our own applications (boo!). Our basic principle has always been to identify the root cause of a security requirement and then comply in a way that goes beyond “ticking the box”; whatever we do has to be useful and practical – and not something we’re ashamed to talk about.
What we want to show:
- Compliance is much harder than security
- but not because the tools can’t do it
- Open Source, and FreeBSD, CAN be used to achieve compliance in the payment industry
- If you implement sane security measures, compliance is nearly free
- The hardest part is explaining what you’ve done and why
Eirik Øverby
Slackware-gone-BSD in the early 00s, escaped the dying world of OS/2 to be doomed to death by Netcraft for another decade. Now managing jailed (but not dead!) systems for a living and as a hobby.
Lessons learned from Sendmail
Eric Allman