Powered by Indico
v3.2.8
The traditional goat BOF. "Groff", the BSD Goat will be in attendance.
This event takes place before the conference officially begins and will be held at Father and Sons, a popular diner, bar and grill near UOttawa. Stop in for a snack and meet up with other early-birds to make some new friends or say hello to old ones!
This tutorial aims at teaching the basics of the BGP Protocol and some of the current best operational practices. The agenda of the tutorial is the following:
Each participants will get a lab environment with routers based on OpenBGPd, FreeBSD + Bird and FreeBSD + FRR.
Basic knowledge of routing is required. A laptop with a working web browser is required.
NSH is a CLI intended for OpenBSD-based network appliances. It replaces ifconfig, sysctl and route with its own simple command language, and encapsulates configuration for other daemons into one place, effectively replacing /etc/netstart and parts of /etc/rc for appliance-style usage.
This Tutorial explains to a user how to install NSH on OpenBSD and build a typical network for a BSD. The Tutorial will include a full interactive lab where users will be able to configure their own firewall, router and and their own OpenBSD Host.
Topics covered in this tutorial would include:
Interface configuration and setup including
- vlan(4)
- bridge(4)
- veb(4)
- trunk(4)
- aggr(4)
- tap(4)
- VXLAN(4)
- GRE(4)
- IP address configuration on interfaces
- DHCP client configuration
- mtu configuration
- IP route management
Diagnostics commands
- show commands
- monitor commands
Configuration management and saving
Bridge / layer2 forwarding confirmation
- protected ports
- STP configuration
- L2MTU IPMTU, MSS and IP fragmentation
- bridge filters
- blocknonip
- bridge rules, tags and interaction with PF
Firewall Configuration rule set configuration and management with NSH
Daemon configuration and management
- DHCPd Server configuration
- SSHd server configuration
Part 2 (if the tutorial session is a full day)
Routing daemon and dynamic routing configuration
- OSPFd configuration
- BGPd configuration
Multiple Routing Domains with NSH
- Route table configuration and management with NSH
- Routing Daemons with multiple routing domains
The OpenBSD Packet Filter (PF) is at the core of the network management toolset available to professionals working with the BSD family of operating systems.
Understanding the networking toolset is essential to building and maintaining a functional envirionment. The present session will teach the principles and hands-on operation of the extensive network tools available on OpenBSD and sister operating systems. Basic to intermediate understanding of TCP/IP networking is expected and required for this session.
Topics covered include
The basics of and network design and taking it a bit further
Building rulesets best pracitces, avoiding common pitfalls in firewall rule construction.
Keeping your configurations readable and maintainable
Filtering, diversion, redirection, Network Address Translation
Handling services that require proxying (ftp-proxy and others)
Address tables and daemons that interact with your setup through them
The whys and hows of network segmentation, DMZs and other separation techniques
Tackling noisy attacks and other pattern recognition and learning tricks
Annoying spammers with spamd
Basics of and not-so basic traffic shaping
Monitoring your traffic
Redundancy of PF firewalls using PF sync + CARP + Ifstatd
Troubleshooting: Discovering and correcting errors and faults
Your network and its interactions with the Internet at large
Common mistakes in internetworking and peering
Keeping the old IPv4 world in touch with the new of IPv6
Using PF and OpenBGPd together to implement an automated, distributed implementation of PF policies
Time allowing and to the extent necessary, we will cover recent developments in the networking tools and variations between the implementations in the sister BSD operating systems.
Participants should bring a laptop, the format of the session will be compact lectures interspersed with hands-on lab excercises based directly on the theory covered in the lecture parts.
This session is an evolutionary successor to previous sessions. Slides for previous PF tutorial sessions are up at https://home.nuug.no/~peter/pftutorial/, to be updated with the present version when the session opens.
Speakers:
Peter N. M. Hansteen, Senior Technical Specialist at Tietoevry. Author of The Book of PF (https://nostach.com/pf3), occasional blogger (https://bsdly.blogspot.com) and lecturer on IT security with a strong preference for OpenBSD.
Massimiliano Stucchi, Technical Advisor at The Internet Society, IPv6 enthusiast, frequent lecturer on network security and IPv6 matters.
Tom Smyth CTO Wireless Connect Ltd. ISP Network operator and security consultant.
Google and Microsoft dominate email, but it's still possible to run your own mail server provided you use modern protocols and maintain acceptable behaviors. This half-day tutorial will take you through configuring your own mail system, from a bare BSD operating system up through SPF, DKIM, and DMARC, and discuss the social rules needed to get your messages into Gmail and Outlook.
We'll discuss:
Unix and email
The Simple Mail Transfer Protocol
Postfix and Dovecot setup
Virtual domains
MX and SPF records
SMTP Protocol Tests
DomainKeys Identified Email
DMARC
Webmail with Roundcube
Rspamd
Escaping and Surviving Block Lists
Attendees will leave with an understanding of how to configure a SMTP server and maintain it in an increasingly challenging environment.
Based on my book "Run Your Own Mail Server."
Transport Layer Security is one of the least well-understood parts of system administration. This tutorial will take you into a deep dive into the management of TLS. We'll discuss:
You'll leave with the understanding of TLS that every sysadmin should have.
Come register ahead of time and meet some of the team!
(Groff the BSD Goat should also be in attendance, if you missed the BOF yesterday.)
The newcomer's session will gather in this room and we'd love to see conference regulars meet new attendees and help them find friendly guides and a trip out for dinner after the presentation! Guests are also welcome to stay and enjoy the hack lounge into the evening.
If you have never been to BSDCan before, show up. We'll have a 15-minute talk about how the con works, then introduce you to experienced BSDCan attendees to help you get the most out of your BSDCan experience.
Experienced members of all projects are requested to attend, help first-timers feel welcome, meet new people, and guide them through an unfamiliar event.
We will also have people from the Family Program in attendance, so bring your spouses to introduce them.
Pick up your packet and badge in the lobby!
In December 2022, Colin Percival assumed the role of Acting Release Engineering Lead for the FreeBSD Project. He managed FreeBSD release engineering for four months, until Glen Barber returned to the role after FreeBSD 13.2-RELEASE.
This is the story of four months of release engineering and a FreeBSD release managed by someone who neither wanted nor expected the job.
Building custom packages for a powerpc or mips network appliance that's too painfully small to build anything itself? With pkgsrc, the customizable cross-platform packaging system from NetBSD, you can cross-build from a large repository of packages on your beefier laptop, workstation, or server instead -- and not just across architectures, but soon across operating systems too.
pkgsrc will automatically handle natively building toolchain packages needed as dependencies to cross-build packages, so you don't have to fuss with manually assembling all the parts of a cross-compiler toolchain in advance. Most packages require relatively little work to adapt to cross-builds.
This talk will discuss the state of cross-compilation in pkgsrc:
Subfiles provide a way for the user to store files ”within” other files. They can be found in a variety of different file systems with a variety of limitations and use cases. Subfiles are not currently available to the NetBSD user. William Dobbins and Philip Nelson attempted to change this in 2016 by beginning a subfile implementation for NetBSD. Their progress has been built upon in this new attempt to implement subfiles by making changes to the user-land, kernel and Fast File System. The success of the project has been proven by rigorous testing, yet there are still things that need to happen to make full integration a reality.
Alamosa is a simple but fast tiered disk cache layer for NetBSD that I have been developing since mid 2023. Loosely inspired by Linux's bcache, Alamosa is designed to provide moderate disk I/O performance gains using small, fast disks as a transparent and flexible block cache.
In this presentation, I will discuss the development and design of Alamosa, the challenges encountered, and performance on Alamosa's target workloads, especially read-heavy SQLite and LMDB. I will also discuss future plans, including support for multi-device cache groups and a new profile-based block eviction mechanism to replace the current least-recently-used structure, as well as the roadmap for submitting Alamosa to upstream NetBSD.
I will talk about using FreeBSD, Zabbix, MQTT, Google/AWS/Nordic clouds, Nordic NRF9160 (a cellular SOC), Zephyr RTOS, and other hardware/software components to create a new service for environmental monitoring of vaccines and medications in pharmacies/clinics/hospitals.
Caveat: At the time of this proposal (2024-01-05), the service is still in development, and not actively deployed in any real life setting, so the "experience" part is lacking at this time.
For this topic, I will have an obvious bias and/or conflict of interest: This references a device and service I have developed, and will be commercially marketing. The BSDCAN audience is not the target market, though, and the presentation will not be a sales pitch. The device and monitoring service will be marketed to pharmacies, clinics, and hospitals in the US.
Projector will show session from 1160 in case the room is overloaded
The FreeBSD open source operating system provides a powerful set of features to facilitate the deployment, virtualization, and serving of Microsoft Windows environments ranging from small research labs to enterprise deployments. Its exemplary integration with the OpenZFS file system and volume manager, its bhyve hypervisor, and its overall unity play key roles in FreeBSD’s ability to perform these three roles and combined with ported third party software, it can facilitate:
Deployment
Windows Product Registration Key Retrieval
Automated Installations
Remote Console and Desktop Access
Virtualization
Server Virtualization
Desktop Virtualization
Serving
Bi-directional NFS, SMB and iSCSI Sharing
Domain Participation
Domain Serving
NTFS Mounting and Management
Data Synchronization and Replication
Native Windows OpenZFS
BATMAN (Better Approach to Mobile Ad-hoc Networking) is a routing protocol for wireless multi-hop ad-hoc networks, which is used and developed by projects such as Freifunk to build open city-scale Wi-Fi mesh networks.
It is implemented as a kernel module in the Linux kernel as batman-adv, which I partially ported to FreeBSD as part of a GSoC project.
This talk will present BATMAN, how it works, and the work done to port batman-adv (how well the port works, what's missing vs Linux, &c). It will focus on the process of using the LinuxKPI for porting drivers from Linux to FreeBSD and its implications for future driver development/maintenance on FreeBSD.
Full description:
This talk will cover:
What BATMAN is, how the BATMAN V algorithm works at a high level, and how/where it's used in real life in practice, i.e., why is it interesting for FreeBSD devices to be able to participate in such networks?
The various components that needed to be changed (aside from porting batman-adv itself, there were smaller changes to surrounding software such as ifconfig, netlink, &c).
A walkthrough of adding a Linux function to the LinuxKPI, and a bit more of a deepdive into the modifications brought to the batman-adv codebase to support FreeBSD to give an idea of how easy/hard it is to bring a driver such as this one in from Linux helped by LinuxKPI nowadays.
My experience with setting up a small BATMAN network in my dorm's neighbourhood.
I will also touch on my intentions to make a port out of this and add support for Wi-Fi in the future (or the current status of the port/Wi-Fi support if I find time to work on those before the BSDCan).
Running a network with its own autonomous system, and speaking BGP can be a daunting task. There is also the misconception that it requires expensive hardware from big vendors. The BSDs are nowadays capable of providing enough routing capabilities to be cost-effective, and there are many tools to manage them and their routing configurations.
In this talk I will showcase why one would need to embark in the journey of running an independent network, what could be used, and some tricks I have learned while managing my own autonomous system number, and running some IXPs leveraging the BSDs.
I will be explaining how to begin, what hardware is better than other, and I will be providing real life examples on how networks are run, considering a series of aspects, including basic configuration, automated filter updating, flow collection and management, monitoring, and more.
Introduction to NSH and how NSH can be used to manage a typical firewall / router for a small business.
OpenBSD is a hugely capable networking operating system which has a broad range of networking features that can support Intra-networking and Internetworking for business. With diverse features like the multitude of VPN / IP tunnelling standards supported and the PF firewall, coupled with Native routing protocol support such as BGP, OSPF & EIGRP, OpenBSD can be integrated fully with just about any enterprise network regardless of size and complexity.
OpenBSD has many native tools built to allow an administrator to configure and support these networking features. NSH Command-line interface sits on OpenBSD and is intended to provide the network administrator with a configuration environment that is intuitive and similar to that provided by many networking appliance vendors on the market.
Configuration tasks such as network interface and IP setup, Firewall and DHCP setup will be discussed and demonstrated.
BOF leader/moderator: Ray Percival
On OpenZFS, fsync() cannot fail - it will wait until the application’s changes are on disk before it returns. If there is a problem, such as a hardware failure, that causes the pool to suspend, then it will block until the pool returns. This could be seconds, hours, or never, depending on the nature on the failure.
Modern distributed systems can often cope with this type of failure by redirecting requests to another node, but they can only do this if fsync() returns an error instead of blocking.
In this talk I describe how OpenZFS implements fsync() and why it blocks when the pool fails. I then discuss a series of changes made to make it possible for fsync() to return failure - and what it means for applications when it does.
Allan from Klara Systems shares a series of stories from supporting users deploying FreeBSD in the field across various industries. These stories come from the silent users of FreeBSD, those that the community often do not know or hear about. Be that because they happen in the quieter corners of industry, where it is not common to discuss the technical challenges you face or how you overcame them, or just from people who are not well connected to the community, or choose not to make waves.
These stories provide insight into how FreeBSD gets used beyond the stories we already know, how it is used in industries that never mention what OS they use, or where you might never expect to find FreeBSD. Sharing these stories can help the community ensure these users continue to get the most out of FreeBSD.
It was a disaster, not of the natural kind, but one that was corporate. Big Corp had decided to reorganize and move my team to another division. Similar to a natural disaster, our team was now homeless and cut off from the essentials: a file server, "desktop" systems, and directory services. Our choices were to ship our fleet of systems halfway across the country to be managed for us or create our own infrastructure. We choose the later using services found in FreeBSD and a handful of third-party packages. This talk will describe how we used FreeBSD to provide auto-mounted home directories, user accounts that worked on any machine, and virtual desktop systems to duplicate our previous setup and how we have subsequently enhanced it.
ZFS’s versatility is unparalleled in the open source world, but users of all experience levels wrestle with its complex command structures with non-intuitive and often destructive defaults.
In this talk, I will share my experience over the last several years of exploring ZFS on a FreeBSD-based resilient private cloud, which led me to create the Zelta Replication Suite, a set of very portable one-true-awk scripts I’ve designed to work as a beginner-friendly approach to backup management while using a modular design that is useful at scale. I’ll describe the maze of ZFS challenges I encountered and how I learned to develop a safer process for managing thousands of backup datasets. I’ll explain how I navigated the challenges, including mount overlaps and other booby traps I set on myself; discuss my processes on how to best avoid these challenges in a DIY environment; and how Zelta can help make enterprise storage management more approachable for every sysadmin.
The talk and demonstration will be divided into three roughly equal parts:
1. ZFS pitfalls and best practices:
2. Implementing a safer process using Zelta’s core design principles:
3. Case studies and examples:
Join our panel of ZFS experts over lunch as they field questions from the audience about ZFS, new features, best practices, and old bugs.
If you deploy ZFS, or are considering doing so, you should join us.
Welcome to the 20th year of BSDCan!
In 2023 the FreeBSD Project celebrated its thirtieth year of providing a complete system distribution. This talk tries to understand what it is that has made FreeBSD one of the few long-term viable open source projects. Most of the projects with long-term successes are sponsored by companies that base their products around the open-source software that they actively nurture. While FreeBSD has companies actively using and supporting it, they have come and gone over the years; none has been the primary long-term proponent of it. Thus the FreeBSD community has been the biggest factor in sustaining the project. Often the community depends on long-term leadership of key individuals, for example Linus Torvolds with Linux. FreeBSD has managed to successfully bring in several new leaders over its lifetime which has been key to its ability to continue to adapt to the new challenges that it faces. This talk is based on the article of the same title that I wrote in the May/June 2023 FreeBSD Journal that had a 30-year retrospective of FreeBSD.
The HardenedBSD Project is a "spork" of FreeBSD that aims to provide the wider BSD community with a clean-room reimplementation of the publicly-documented bits of the grsecurity patchset for Linux. The cofounders of the project started collaborating in 2013, and the project become official in 2014.
HardenedBSD goes above and beyond its original goal by providing extra security enhancements, exploit mitigation strategies, and unique access into our infrastructure. We seek out ways to serve in global human rights endeavors, navigating the nexus between {cyber,info}sec and human rights.
This presentation recaps the last decade of development and dives into where we aim to go in the next one, five, and ten year periods. We give tangible (yet sanitized) examples of the impact of our human rights focus.
20 Years of NYC*BUG
and can we handle 20 more?
NYC*BUG (https://www.nycbug.org/) launched in January 2004 with a motley group of previously disconnected souls. We kept sponsors (mostly) at a distance, and have remained a strong example that many others want to emulate.
NYC*BUG persisted for 20 years now, and earned an impressive resume of successes:
five cons (https://www.nycbsdcon.org/), which if they were profitable, the funds went to the BSD projects
reasonably consistent monthly meetings, until COVID, which acted as a conveyor belt for new BSD users, contributors and speakers
maintaining a cabinet with some important services, from 80's BSD code archives and OpenBSD ftp4.usa, to a smoketest box for Perl, not to mention some critical Tor services
other smaller successes with remarkable longevity and relevance, like dmesgd
More generally, our consistency and decent organizational setup has created an illusion that NYC is some BSD-heavy city. Amid the old plethora of civil-war engaged Linux groups, we stood out as a sane pillar of technical events.
There was a secret ingredient in NYC*BUG that wasn't always elaborated for all: we adopted the pop sociology concept of the "starfish" as opposed to the "spider." We didn't formalize into a nonprofit, we have no real assets, and there's no intense commitments. Come as you are.
The 20 years is filled with some less-known stories:
how we were dismissed then loved by a particular developer
when Steve Jobs wanted us kicked out of the Soho Apple Store, then decided he actually wanted us there
Yet we're also at a pivotal moment. Post-COVID, the non-profit, data-collection user group scene is dead. The BSDs aren't as attractive in themselves, as is true for Linuxs too, as the new generation lives in the cloud.
This presentation will explore those 20 years, and provide some ideas for how local technical user groups can keep relevant for the forseeable future.
OpenBSD provides the utility fw_update(8) to handle firmware loading for hardware from manufacturers whose licensing isn't compatible with our base system. We will take a trip into the history of fw_update(8), its structure and why it exists. A recent rewrite provides an illustration of the value OpenBSD places on simplicity and user experience.
The RISC-V port in NetBSD has been years in the making with the most recent efforts bringing success to the project. To enable the successful port, NetBSD needed to gain some supported technologies and undergo some structural changes to facilitate the requirements and recommendations accompanying the RISC-V platform. As the majority porting efforts targeted a virtual platform, physical hardware support has also been confirmed, though not without its own difficulties in addition to the software-side of the port. This document aims to recount the progress of the RISC-V port in NetBSD, lay down the foundational knowledge needed to understand the port structure in NetBSD, and articulate the considerations and difficulties that might be encountered in expanding the RISC-V hardware support in NetBSD.
Missed your packet/badge pickup on day one? Someone will be in the lobby to help you.
"It's impossible to run your own email!" Not quite. But you must do it carefully and correctly.
This talk discusses the current state of email, with a focus on the small independent server operator. What do you need to run your own mail? How can you use protocols like DKIM and DMARC without wrecking your ability to communicate with the outside world?
Based on my book "Run Your Own Mail Server."
Pointers have provenance which is the notion that pointers to separate objects of different origins are distinct regardless of the pointer’s address value. This is true in systems programing languages include C, C++, and Rust and deterministically enforced by hardware and software on CHERI systems (systems such a Arm’s PAC and MTE also provide probabilistic enforcement).
We developed address space reservations (hereafter reservations) to support CHERI’s strict provenance model. Reservations are implemented in the vmsystem and exposed by the mmap() family of system calls. In this talk I will describe the design of reservations and the compatibility constraints that drove the design. Further, I will explain how adapting existing code to reservations can improve correctness across the entire ecosystem.
You've used a BSD, but have you used the open source of it to bend it to your will? Does it grant you freedom, or just confine you to a different set of bugs?
This talk will tell the story of how I got into hacking NetBSD with zero experience in kernel development, and how you can get started with things too even if you aren't an experienced kernel hacker, including:
For beginners and experienced C hackers alike!
This talk introduces the low level debugger (LLDB) kernel module debug facility for the FreeBSD kernel. The current functional status of LLDB within the FreeBSD kernel is attributed to contributions from [1] and the collaborative efforts of the community. Key functionalities include core dump parsing and memory context building for the coredump, specifically integrated into the process plugin within LLDB for the FreeBSD kernel.
This enhancement equips LLDB for effective post-mortem debugging on the FreeBSD kernel. While the implementation of the process plugin has been successfully completed, the paper emphasizes the imperative need to implement the DynamicLoader plugin for the kernel loader.
This plugin plays a critical role in loading the symbol file of the kernel module, ensuring comprehensive parsing of symbols for loadable kernel modules.
Additionally, given the potential existence of the kernel module as either a relocatable file (for x86) or a shared object (for ARM), the implementation should confirms the usability of both types of ELF format kernel modules.
After cherishing the discourse that surrounded his talk "BSD for Researching, Writing, and Teaching in the Liberal Arts" at BSDCan 2023, the nutty assistant professor of theology Dr. Corey Stephan is returning to BSDCan with a new merger of his scholarly craft and his use of free and open source software. This talk showcases Stephan’s intended interdisciplinarity in its very title: Summa Tetraodontidae, “Summa (Summary) of the Pufferfish,” is a play on the names of the countless Summae projects of the late Latin Middle Ages, especially the famous Summa Theologiae of Thomas Aquinas.
While nodding thoughtfully toward other key BSD operating systems (notably, FreeBSD and NetBSD), Stephan will focus the bulk of his attention in this talk on desktop OpenBSD. Stephan will cheekily adopt elements of Thomas’s communicative style – perhaps even preparing an articulus (or two) with obiectiones, a sed contra, a respondeo, and responsa ad obiectiones – as a way to explore OpenBSD's internal orderliness.
Stephan’s guiding thesis will be that desktop OpenBSD is overtly ‘scholastic’ in character. OpenBSD is, after all, (intensely) logically ordered. As a desktop operating system, OpenBSD is supposed to ‘just work’ – and cleanly so, with everything from the installation process itself to WiFi configuration to installing key research and writing software applications (from LibreOffice to TeXLive plus a GUI BibTeX manager and a GUI LaTeX editor) being radically simple. The project’s leaders reject what is not logically ordered ipso facto. Everything about how OpenBSD works is documented in an accessible, systematic way.
OpenBSD possesses an orderliness that even a persnickety medieval scholar like Thomas Aquinas could appreciate.
This talk presents a pioneering initiative to integrate OpenStack, an open-source cloud computing platform, with FreeBSD, a robust Unix-like operating system. Traditionally, OpenStack has been closely associated with Linux-based environments, leveraging specific Linux features and technologies. This integration aims to expand OpenStack's applicability by harnessing FreeBSD's advanced networking, security, and efficient resource management capabilities.
The project scope involves adapting OpenStack's key components to function seamlessly within FreeBSD's system architecture, focusing on virtualization with bhyve and FreeBSD's unique networking stack. A Proof of Concept (PoC) has been successfully developed, demonstrating the viability of this integration and laying a foundation for further development.
We address several critical challenges in this integration process, including adapting libvirt for bhyve, leveraging Open vSwitch to connect VMs to the network, and ensuring security group functionality. The project also tackles the adaptation of OpenStack's oslo.privsep library to FreeBSD's privilege model and addresses the complexities of nested virtualization and VM console access within FreeBSD.
Future work involves expanding the integration to more OpenStack components, enhancing system performance, and fostering collaboration within the FreeBSD and OpenStack communities. This integration represents a significant advancement in cloud computing, offering a versatile platform that combines the strengths of both OpenStack and FreeBSD. The project invites collaboration and contribution from the community to overcome the challenges and fully realize the potential of this innovative integration.
At the start of 2023 I traded my 20-year career as a Linux sysadmin for a new life as a full time OpenZFS developer. Going great, thanks for asking!
Because fast iterative development sucks when you need to wait for a reboot after every kernel panic, I wrote quiz, a tool to make fast edit-compile-test cycles on kernel code possible. Under the hood it uses QEMU's "microvm" profile and a custom kernel config to boot from cold into the OpenZFS test suite in a couple of seconds. Its great, and I use it hundreds of times a day.
My FreeBSD-using colleagues naturally said "cool, but what about us?!" so I started looking at what it would take bring quiz to FreeBSD. The answer to that is "its complicated", and involves either adding bhyve to QEMU as a hardware virtualisation backend, or adding support for direct kernel loading support to /usr/sbin/bhyve. "Why not both?" I said, before promptly shriveling into a corn cob.
This talk will show you quiz in action, present the Linux direct boot sequence and show how I taught bhyve about it, also show how QEMU would like to work and why it doesn't quite line up with bhyve's view of the world, and hopefully show you how low-level kernel hacking for any OS can be made as simple as hacking on any other program.
Last year, Colin Percival made FreeBSD a viable Firecracker guest by first enabling the kernel to boot from PVH, and then fixing and adding necessary features for it to be capable to boot and run a usable userspace.
Using his previous work in performance, he successfully booted a FreeBSD virtual machine in less than 25ms.
Taking on his work, discoveries and fixes, NetBSD is now capable of booting as a PVH guest and boot in less than 20ms.
NetBSD has been capable of booting using Qemu's -kernel flag using multiboot in i386/32 bits for quite some time, but amd64 patches never made their way to the source tree. Meanwhile, a newer and increasingly popular method in order to boot a guest without bios and bootloader appeared, a mode brought by Xen called PVH boot.
Some low level adaptations were necessary in order for the NetBSD kernel to boot using PVH, but it can now also start from Qemu without bootloader, either with a classic machine emulation or using the newer, faster microvm model.
In order to use the latter, more work was needed as both Qemu's microvm and AWS's Firecracker can use VirtIO's latest memory mapped device feature: MMIO.
Again, MMIO mode is heavily inspired by Colin's work, but NetBSD device driver handling being quite different from FreeBSD's, some extra work was needed to make it happen.
Last but not least, we will look at some modifications that were necessary in order to bring the boot time down from about 300ms to less than 20.
Computing has its warts, fun and rewards, but sometimes other creative urges come to light, such as DJing and music production. How do we leverage our favourite operating system family to act on said creative urges?
i wish more ppl could realise their creative urges --friend
This programme will cover the tooling and setup needed for anyone to start DJing and producing music, using as much open source as possible. Those familiar with or interested in other aspects of signal processing may see some parallels in concepts like flowgraph design and implementation. Some discussion may ensue about states of the audio subsystems in the operating systems.
While the focus is not on the artistic sides of DJing and music production, a demo involving turntables and vinyl control may be included.
This talk will focus on a userspace implementation of the TCP transport for NVMe in FreeBSD as well as a simple userspace host (client) and controller (server). This will include a description of the transport-independent abstraction layer in libnvmf including the transport switch structure transports such as TCP implement. For the host, the talk will describe the nvmfdd test client showing how read and write requests are mapped into Fabrics commands and dispatched via the transport-independent layer. If there is time, the talk will also discuss a userspace controller (nvmfd) and how it exports local files or ram disks as remote fabrics namespaces.
I operate a small network with both local and remote systems that share a single bastion WireGuard gateway to the Internet. Some WireGuard client applications, such as WireGuard for Android, allow application-level granularity selection for routing traffic via the VPN or not. OpenBSD does not have a client application. It uses a kernel driver, which doesn't make routing decisions. Instead, routing is controlled by the kernel"s routing table or tables.
When I first deployed WireGuard, I deployed a single routing table, and used routing priorities to route traffic via the VPN if happened to be active and operational, enabling the VPN or disabling it as needed. Eventually, I switch from a single routing table to two, using OpenBSD's routing domains facility.
This transition afforded me the ability to cease using an all-or-nothing VPN with a single on / off control, and to have application level granularity. OpenBSD admins determine routing domain selection at process initiation via the route(8) exec feature.
Josh has been an OpenBSD user for 20 years. He still enjoys the OS, and continues to maintain a handful of ports for the Project. He lives in Michigan with his daughter's two cats.
Standards development and application at the Operating System (OS) level are in a complex and evolving state. This talk will not only explore what it means to be POSIX compliant, but will focus on the question: What is the status of POSIX compliance within the BSD sphere in 2024? What are the drivers for POSIX compliance today?
This talk will explore what POSIX compliance means and whether BSD is officially POSIX compliant. Feedback from the community will be appreciated, and a discussion of the community's concepts of the value of POSIX will be sought.
A comprehensive look at contributing to FreeBSD via Github. In addition to the basics of how to create a pull requests, we'll explore how to structure your submissions to spped their acceptance. You'll learn the criteria used to evaluate the submission, what is and isn't acceptable. You'll learn about tools to use to test your submission for compliance with style, proper man page construction, and shell script linting. I'll cover copyright and license issues. I'll briefly cover writing tests. I'll discuss what to expect from the review process, what to do if the reviews are slow to come in. I'll cover when to use phabricator or bugzilla instead. This will touch on the basics with pointers in the slides to more detailed treatment of all these topics.
It will be geared to the first time contributors to FreeBSD of all abilities to code, write or port. The goal will be to teach how to make a good submission and take the mystery and uncertainty around it away.
Can many hands and many pockets contribute to sustainable code development without burdening the projects that will have to maintain the code on an ongoing basis?
This talk is an AMA format and propose a 15-20 minute talk and 30 minute Q & A session afterwards.
Everyone who pays gets food & drink. Alcoholic beverages will be available for purchase.
The venue is generally ours for the entire evening, there is no rush to leave.