AsiaBSDCon 2026

Running FreeBSD on WSL2 Without Modifying FreeBSD: A Working Implementation
2026-03-22 , Room B

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

Balaje Sankar is an Enterprise Cloud Architect and long-time FreeBSD enthusiast. With a background in network programming and C, he focuses on systems virtualization and cross-platform compatibility. He is the author of the WSL-For-FreeBSD implementation.