AsiaBSDCon 2026

FreeBSD Developer Summit is an invited-only event for FreeBSD project members. For more details, see https://wiki.FreeBSD.org/DevSummit/202603

The FreeBSD Ports Collection is one of the largest third-party software repositories in the open-source world. According to Repology, it ranks in the top four in terms of the number of packages, maintainers, and up-to-date packages. Alright, that's all fine and dandy, but how does it work? What is this mystical ports framework? Why is it so powerful?

The workshop has 3 parts: user usage, ports maintenance, and framework development. The ports framework is a dense codebase and you'll need a map to navigate it. This workshop is the map. The workshop's goal is to raise your confidence in using ports, help you understand the framework's current limitations, and enable you to modify the framework and contribute those changes back.

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 both teach principles and provide opportunity for hands-on operation of the extensive network tools available on OpenBSD and sister operating systems in a lab environment. 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

• Keeping your configurations readable and maintainable

• Seeing what your traffic is really about with your friend tcpdump(8)

• 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

• Resilience, High Availability with CARP and pfsync

• 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

The tutorial is lab centered and fast paced. 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 for the hands on labs part and for note taking. 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 the most recent version of the PF tutorial session are up at https://nxdomain.no/~peter/pf_fullday.pdf, to be updated with the present version when the session opens.

This tutorial delves into the practical application of FreeBSD Jails, specifically focusing on enhancing their usability and orchestration using powerful tools: iocage and Ansible. The examples presented herein are derived from and complement the official documentation of the proposed collection, offering a hands-on approach to managing complex jail environments. This guide is tailored for advanced FreeBSD users who possess a working knowledge of: FreeBSD operating system fundamentals, the iocage utility for jail management, and Ansible for configuration management and automation. The goal is to move beyond basic jail creation and demonstrate how to effectively orchestrate a production-ready jail infrastructure. As a preparation for this tutorial, the users are encouraged to read the documentation and test the proposed collection. The source code is available at GitHub.

FreeBSD Developer Summit is an invited-only event for FreeBSD project members. For more details, see https://wiki.FreeBSD.org/DevSummit/202603

This tutorial is for those who have not yet jumped on the IPv6 bandwagon.

The goal is for participants to be able to understand how IPv6 works, how an addressing plan could be built for an enterprise network, and how this can be configured on FreeBSD and OpenBSD.

We will also configure services to work on IPv6 and discuss the implications of configuring PF rules for them.

To complete the tutorial, we will configure an IPv6-mostly network, where IPv6 is a first-class citizen and IPv4 is not. This should give participants enough confidence to configure IPv6 in their own environment.

The tutorial is supported by a remote lab where every participant will be given a series of virtual machines to configure following the topics presented in the theory sessions, and will also have to relate to others to complete the required exercises, like setting up web services and interacting with other groups to test their communication on the live internet.

The NetBSD Foundation is looking forward to organizing a NetBSD devsummit at AsiaBSDCon 2026.

The primary focus of this are NetBSD and pkgsrc developers, but others may join too.

The details of the summit are yet to be planned in detail, but overall the idea can be summarized as sharing knowledge about things in NetBSD and pkgsrc that are not (yet) known to many other developers and in general connecting NetBSD and pkgsrc developers. Some potential topics for the devsummit are PGP key signing, NetBSD 11, and knowledge sharing about personal development
environments.

A wiki page is available on the NetBSD wiki and the schedule will be kept up to date there: https://wiki.netbsd.org/summits/asiabsdcon_2026_netbsd_summit/

The formal openning of AsiaBSDCon 2026

Major production-grade Operating Systems (OSes), such as the BSD OSes, have continued to advance thanks to the substantial efforts of their developer and user communities.
This talk explores the question of whether there are other possible forms of OS functionality development that can accelerate development velocity while reducing the burden on these communities.
Specifically, we discuss what a software architecture should look like to enable the easy incorporation of implementations developed by different parties in a decentralized manner, without introducing significant performance bottlenecks.
The discussion will be informed by the speaker’s experiences with the development of a portable TCP/IP stack [1] and the exploration of approaches for implementing OS functionalities in user space [2, 3, 4].
To conclude, I would like to humbly put forward several modest feature requests for the BSD community.

[1] https://doi.org/10.1145/3687230.3687233
[2] https://www.usenix.org/conference/atc23/presentation/yasukata
[3] https://doi.org/10.1145/3721462.3770771
[4] https://doi.org/10.1145/3678015.3680481

Virtualisation technology has gone a long way. It began as early as the 1960s with IBM CP/CMS, and was even available as Open Source back then. On modern hardware though, the technology exploded in the mid-2000s, and has become a new normal in the form of containers since 2014. BSD systems have both pioneered and lagged behind on different aspects, between innovation and catch up with the latest industry standards. The gang of NetBSD, EdgeBSD, and smolBSD projects is no stranger to this: coming from the desert, it is now proudly lining up for drag races to the boot finish line, still plundering ideas and patches all over to solve the case.

Logstor uses the idea from log-structured file system to build a virtual disk on top of a physical disk. It is a virtual disk so its size can be larger then the underlying physical disk. It’s log-structured so it treats the underlying disk as a log and transforms the write requests from upper layer file system to log append operations. Since the random write operations are transformed to log append, the random write operations are transformed to sequential write operations.

Logstor is implemented by using FreeBSD’s GEOM framework. This is the second version of this program. The differences with the previous version are:
* The previous version runs in user-level and this version runs in kernel.
* Remove garbage collection and replace it with Stale Sector Recycle (SSR).
* Add new logstor commands snapshot and rollback.

Snapshot command is used to take a snapshot of the virtual disk and the rollback command can revert the virtual disk back to its previous snapshot.

Casper, a userspace library in FreeBSD, provides system services such as DNS resolution to applications confined by Capsicum. However, these Casper services execute with normal privileges, exposing the system to potential security threats including privilege escalation and unauthorized resource access. To address this issue, we present a sandboxing mechanism for Casper based on FreeBSD’s Mandatory Access Control (MAC) framework. Our design confines Casper services within MAC-enforced domains, thereby limiting their privileges and isolating their interactions with the system. We evaluate the proposed mechanism across multiple Casper services and show that it strengthens system security while incurring less than 16\% performance overhead.

The open-source tool STUNMESH-go helps devices create WireGuard connections when they all sit behind NAT or CGNAT networks. These network setups make it hard for devices to connect directly to each other. NAT and CGNAT are common in many situations: home networks, mobile networks, and enterprise networks. The tool uses STUN protocol to help devices find their public IP addresses and ports. It has a special feature: it can use the same port for both WireGuard and STUN traffic by working directly with the WireGuard kernel module. This approach is more efficient than solutions using embedded wireguard-go with a proxy setup, like Tailscale does. It means devices can connect directly without needing a central relay server. This saves bandwidth and reduces latency.
STUNMESH-go works well on Linux systems. This means it already supports popular network solutions like VyOS and OpenWrt. However, many network devices and firewalls use FreeBSD-based systems. pfSense and OPNsense are two popular firewall systems that run on FreeBSD. To support these important platforms, we needed to add proper FreeBSD support. Also, macOS support is valuable for developers and network engineers who want to test and develop P2P VPN solutions on their computers. In this work, we added full support for FreeBSD and macOS. This helps developers and network engineers who use BSD or Apple systems to build P2P WireGuard networks, even when they are behind NAT or CGNAT.
We explain the technical problems we met during this work. On Linux, STUNMESH-go uses raw sockets with BPF filtering. This lets it watch all network interfaces at the same time. But FreeBSD and macOS work differently. They use BPF with interface-specific packet capture. We had to write code that listens on all network interfaces for STUN messages, but not on the WireGuard interface itself. This design works better when systems have multiple network connections or backup routes. We tested this with OPNsense virtual machines to check that it works correctly in real firewall situations.
We also added the health monitoring system to both platforms. This system checks if the tunnel is working by sending ping messages to each peer. If a connection fails, it tries to reconnect automatically. It uses smart retry logic with exponential backoff. This means it waits longer between each retry attempt to avoid overloading the network. Each peer can have its own ping settings with different timeout and interval values. This feature is very useful for mobile networks and changing network situations common on BSD and macOS. In ideal conditions, when network changes happen, the system can detect the connection problem and reconnect quickly.
The tool has a plugin system that we also ported to these platforms. STUNMESH-go supports different key-value storage backends through plugins. Users can even write custom plugins using the exec plugin interface. We made sure this plugin system works on all platforms. Users can connect to various DNS providers or key-value storage services like Cloudflare. This helps with automatic peer discovery and configuration sharing. When a peer's IP address changes, it updates the DNS record automatically. Other peers can then find the new address and reconnect. This works well with WireGuard's built-in roaming capability. As the WireGuard documentation describes, the server finds peer endpoints by checking where authenticated data comes from. If endpoints change, both client and server update their settings by learning from where they receive correctly authenticated data. This means there is full IP roaming on both ends. STUNMESH-go uses this feature by helping peers discover their new public addresses quickly through STUN and updating the shared configuration storage.
We successfully built and ran STUNMESH-go on FreeBSD and modern macOS versions. We set up full-mesh P2P networks with nodes behind NAT or CGNAT. We tested that direct P2P connections work reliably on these platforms. Our tests included VyOS routers with LTE modems, OPNsense firewalls running on FreeBSD, and mixed environments with BSD, macOS, and Linux nodes. We did not measure detailed performance like latency or speed. Our main goal was to check that connections work in real network conditions. The results show that BSD and macOS platforms can run direct P2P WireGuard networks using STUNMESH-go reliably.
We share our experience and future directions. Important insights include how to handle networking across different platforms in Go, best ways to prepare build environments on Unix-like systems, and why good documentation matters for platform-specific setup. We also worked with BSD and macOS communities to get feedback and support. This helped us find unusual problems and platform-specific issues. Future work includes making the build process easier, improving documentation for BSD and macOS users, and helping more people in these communities use P2P network tools. We also plan to add support for more BSD variants and improve the testing framework for firewall platforms like pfSense and OPNsense.

This paper introduces the Bhyve Management Daemon (hereafter BMD), which manages bhyve virtual machines according to configuration files. BMD is not a replacement for existing bhyve management tools. The design focuses on lightweight, simple configuration and secure operations for unprivileged users.

Over the past few years, I have observed that the misuse of AI in education for cheating purposes has created significant challenges in assessing students' authentic contributions. Another issue I identified is that university labs rarely teach the kind of problem-solving skills that are relevant in real-world scenarios — the kinds of problems graduates will face in their professional lives, such as fixing production issues. Traditional assignments often lacked real-world relevance and, because they could easily be solved with AI assistance, left students unprepared for professional challenges.

To address these shortcomings, I developed — as part of my master’s thesis at the University of Applied Sciences, Darmstadt, Germany — a new teaching framework that leverages Chaos Engineering and Gamification to modernize Unix education on FreeBSD. With my new system, instructors can simulate realistic problems that students must solve using system administrator permissions. I also designed the framework to make it difficult for participants to “cheat” using AI, and I evaluated its effectiveness through a controlled test with a group of students.

In my presentation, I introduce this “Chaos Education System”, which I tested in the Unix for Software Developers course at the university. The name is inspired by the concept of chaos monkey systems, which intentionally “wreak havoc” on production systems to improve their resiliency and train system administrators to diagnose and repair failures. My approach enables instructors to inject intentional faults (error scenarios) into student-managed FreeBSD jails. The students must then identify, resolve, and prevent these issues from recurring using standard system administration tools — including full root permissions.

To increase student motivation and simulate real-world “production pressure,” I implemented a global highscore list as a gamification element. Each time an issue is solved, the system awards points based on elapsed time and an instructor-defined difficulty bonus. After each exercise, a post-mortem group discussion allows students to share their solution approaches, compare methodologies, and reflect on lessons learned. Through this process, students gain valuable practical skills such as troubleshooting, system recovery, and proactive system management — all within a realistic and dynamic environment that traditional “one-size-fits-all” assignments fail to provide.

I built the entire system using BSD-licensed open-source components, including FreeBSD, pf, VNET, Bastille jails, and templates. Shell scripts act as the glue, connecting these technologies and implementing the logic for the chaos monkey framework. I tested the prototype with two groups of 16 students each in January 2025. One group was allowed to use ChatGPT during the exercises to assess whether AI assistance improved their performance (if at all). Insights from this testing were used to refine and enhance the system further.

In my talk, I will present the concept and implementation of the Chaos Education System, demonstrate its functionality, and discuss potential future developments. FreeBSD has proven to be an outstanding foundation for this project due to its modularity, open-source availability, low resource consumption, and excellent documentation. I believe the system can be expanded beyond academic use — for example, in corporate training or workshop-style events. It allows instructors or trainers to easily create and deploy custom scenarios, scaling efficiently to multiple parallel users thanks to the lightweight nature of FreeBSD jails.

Audience: This project is aimed at educators, trainers, and system administrators interested in modernizing Unix/Linux education through hands-on, interactive methods. Managers and team leads may also find the system useful for training employees through customized scenarios that replicate their own production environments.

While Linux containers benefit from a rich ecosystem of Container Network Interface (CNI) plugins such as Calico and Cilium, FreeBSD Jails have lacked native, standardized solutions for advanced networking. As a result, users have relied on manual, error-prone configurations, which limit scalability and integration with modern orchestration platforms.

This presentation introduces porting Calico, a widely adopted CNI plugin, to the FreeBSD operating system. Our approach replaced Linux-specific components with FreeBSD-native equivalents: iptables with ipfw, netlink sockets with routing sockets, and Linux network namespaces with FreeBSD's VNET.

This work aims to bridge the gap between Linux and BSD container networking. By providing scalable, policy-driven capabilities that are compatible with existing Linux-centric infrastructure, FreeBSD will be empowered to participate more fully in the broader container networking ecosystem.

This paper presents a redesign of PC classroom infrastructure using FreeBSD and its native hypervisor, Bhyve. The proposed system addresses limitations of current Proxmox VE based virtual machine deployments by enabling direct hardware control and improved system flexibility. Key contributions include a user-friendly guest-switching mechanism, an accelerated deployment system utilizing ZFS incremental backups, and an integrated screen sharing solution for enhanced classroom interactivity.

Modern computers are collections of heterogeneous components, including GPUs, TPUs, NPUs, FPGAs and other devices that carry out computing tasks but which are not the central CPU. We are proposing novel methods of program compilation, transformation and scheduling that take advantage of the entire system so that computation takes place in the most appropriate place at the most propitious time. Using LLVM IR, optimizers, and a performance aware scheduler, we can maximize utilization while reducing execution times for arbitrary workloads, freeing developers from treating modern computers as if they were fixed function platforms. This research has applications in high performance computing, embedded systems and security due to the centrality of run time program transformation in our system.

After a decade and a half of academic and industrial research, products using CHERI to provide hardware enforced, deterministic memory safety are making their way to market. CheriBSD, a research fork of FreeBSD, has been the primary vehicle for operating system research on supporting CHERI's memory safety and compartmentalization potential. We are now bringing the most complete and stable work from CheriBSD to FreeBSD with the goal shipping FreeBSD 16 with spatial and temporal memory safety. This talk will motivate this upstreaming, explain our plan, and cover progress to date. We hope to update the FreeBSD community on our progress and encourage other BSDs to learn from our adoption of CHERI.

Author: Balaje Sankar
Repository: https://github.com/BalajeS/WSL-For-FreeBSD
Abstract
This work presents a successful and practical implementation of running FreeBSD on Microsoft’s Windows Subsystem for Linux version 2 (WSL2) without modifying the FreeBSD base system. With the recent open-sourcing of WSL2, it became possible to examine whether the subsystem’s VM-based environment could support a non-Linux guest with minimal changes on the Windows side. The resulting prototype demonstrates that FreeBSD can be booted reliably inside WSL2 using a full disk image, provides a fully functional and responsive console, and operates with performance comparable to a Linux distribution running under the same subsystem.
1. Introduction and Motivation
The motivation for this project comes from longstanding community interest in seeing FreeBSD operate under WSL2. Prior to WSL2’s open-sourcing, the feasibility of this was unclear, as external reports primarily focused on Linux-specific behaviour. Once the source code became available, the architecture could be studied in detail.
2. HCS - VM Orchestration and Lifecycle
A key early finding was that WSL2 does not depend heavily on traditional Hyper-V management interfaces but instead orchestrates virtual machines through the Host Compute Service (HCS) API. HCS provides a more generic VM lifecycle and resource description mechanism. A small test program using HCS APIs confirmed that FreeBSD could be instantiated within this framework, indicating that the subsystem did not impose a Linux-only restriction at the virtualization layer.
3. Implementation Challenges
The next major challenge was obtaining usable console output during boot. WSL2 typically uses a virtio-console for interactive output in Linux distributions. However, FreeBSD does not currently support virtio-console output for early boot messages, resulting in a stuck boot process when enabling virtio-console in HCS configuration.
To resolve this, the system was configured to boot using a serial console, which FreeBSD supports robustly. With serial I/O enabled, FreeBSD’s kernel and userland initialization proceeded without issue, providing a clear view of the boot sequence and allowing interactive access to the system. Testing showed that the resulting console performance is effectively on par with Linux WSL2 instances, with low-latency input and smooth terminal behaviour.
4. hvsock - Host-Guest Communication
Host–guest communication within WSL2 relies heavily on Hyper-V sockets (hvsock), and supporting these was another necessary step toward full integration. Experiments were conducted to verify that FreeBSD’s hvsock implementation could function in this environment. These tests confirmed that FreeBSD can operate as both an hvsock client and server, enabling it to participate in the minimal handshake mechanisms the subsystem expects from its guest systems.
Based on this, two small utilities—hvinit and hvbridge—were developed. These programs perform the initialization exchanges needed for WSL2 to treat the FreeBSD VM similarly to how it treats a Linux distribution during early startup, without requiring any changes to FreeBSD itself.
5. Boot Strategy
Standard WSL2 Linux workflows heavily modify the boot process, often relying on a host-provided kernel and a specialized initrd (minit init) to bootstrap the environment. In distinct contrast, this implementation enforces a strict 'stock-only' policy for the guest.
By leveraging the HCS API’s native capability to boot full disk images, we bypass the Linux specific kernel loading mechanism entirely. This approach eliminates the need for custom kernels or minit-init type custom init programs. It demonstrates that the unmodified FreeBSD base system is robust enough to operate within the WSL2 architecture.
6. Limitations and Future Work
Networking and host filesystem integration remain areas for future work. Although WSL2 uses the Host Compute Network (HCN) API to configure networking for Linux distributions, this project has so far only explored HCN behaviour conceptually and generated example configurations. No guest-side networking setup for FreeBSD has yet been implemented, and WSL2’s Plan9/9P filesystem integration has similarly not been enabled. These features remain logical next steps, particularly networking which will significantly increase the prototype’s usability.
7. Conclusion
This paper demonstrates the technical feasibility of running successfully a stock FreeBSD environment natively on Windows via WSL2. It suggests a future where developers and students might experiment with FreeBSD tools without the need for dual-booting or dedicated hardware. By establishing that the underlying virtualization architecture is compatible with FreeBSD, this work provides a foundation for the community to further refine the experience and expand the FreeBSD ecosystem to a wider audience.

Source Code: https://github.com/BalajeS/WSL-For-FreeBSD
Demo: https://x.com/balajesankar/status/1970585411153207715?s=20

Modern laptops have largely abandoned the legacy ACPI S3 sleep state in favor of low-power idle states collectively known as S0ix. As a result, operating systems that rely on S3 for suspend-to-RAM functionality are increasingly unable to provide effective sleep support on contemporary hardware.

This talk presents ongoing work to implement suspend-to-idle (s2idle) and S0ix (specifically S0i3) support in FreeBSD. We describe the architectural differences between S3 and S0ix, the necessary kernel infrastructure for suspend-to-idle, platform coordination via ACPI System Power Management Controllers, and vendor-specific requirements, with a focus on AMD platforms.

In this talk, we present the mac_do(4) and mdo(1) FreeBSD components, which aim at supporting a role-based security model by allowing controlled process credentials transitions, and do so without the use of setuid executables by leveraging instead the mac(4) framework. We describe their architecture and illustrate their practical functionalities to administrators and users.

The mac_do(4) kernel module has been introduced to allow unprivileged processes to change credentials, provided the requested changes are explicitly allowed by rules set by an administrator. Its companion userland program, mdo(1), serves to request credentials changes.

Both components have undergone major changes that have been shipped into FreeBSD 15. First, thanks to a redesign of mac_do(4)'s rules, it is now possible to completely specify the full sets of user and group IDs that must be present or absent in the final credentials for a transition to be accepted. Second, mac_do(4)'s configuration is per jail, allowing different sets of rules as needed or inheritance from the parent jail. This configuration can be tuned from inside and outside the jail. Third, mdo(1), initially limited to changing users and possibly switching to their groups, has grown the ability to fine-tune the target credentials' users and groups while retaining simplicity for the most common use cases.

We will describe how mac_do(4)'s credentials rules work, what you can accomplish with the mdo(1) companion program in FreeBSD 15, and the changes that are in the works at time of this writing. Some of them have been developed as part of Google Summer of Code 2025, which also gave birth to the new mdo(1) features described above, and are in the process of being integrated, such as per-jail configurability of "approved" companion programs for mac_do(4). In general, more logging, auditing and ease of use facilities are to come next. We will report on the progress of these new features.

We will also touch on some aspects of the implementation, notably why we needed to introduce the new setcred(2) system call, which allows to change all process credentials in a single call, and, time-permitting, those that are related to the use of some FreeBSD's kernel sub-systems (notably, sysctl, jails and OSD).

This session invites you all to give short talks about your ongoing projects.

The formal closing of AsiaBSDCon 2026