Microsoft Reveals How Its Windows 10 Linux Subsystem Works

The Bash on Ubuntu on Windows enables native Linux ELF64 binaries to run on Windows via the Windows Subsystem for Linux (WSL). Although many people were shocked by the Bash on Ubuntu announcement, it is worth mentioning that it opens new doors for the compatibility between different operating systems. Microsoft takes another step forward and reveals how its WSL works so we can better understand how the two systems communicate with each other.

WSL was created by the Microsoft Windows Kernel team and contains both user mode and kernel mode components. More specifically, the system is composed of:

a user mode session manager service handling the Linux instance life cycle
Pico provider drivers (lxss.sys, lxcore.sys) whose role is to emulate a Linux kernel by translating Linux syscalls
Pico processes hosting the unmodified user mode Linux (e.g. /bin/bash).

The connection between the three components is described as follows:

The main challenge in the process is to make the two systems work together:

It is the space between the user mode Linux binaries and the Windows kernel components where the magic happens. By placing unmodified Linux binaries in Pico processes we enable Linux system calls to be directed into the Windows kernel. The lxss.sys and lxcore.sys drivers translate the Linux system calls into NT APIs and emulate the Linux kernel.

Taken into account Microsoft’s interest in open-source platforms, many people wondered whether the tech giant should acquire major Linux- focused companies such as Canonical, the company behind the Ubuntu operating system. Although Microsoft and Canonical cooperated on open-source software, neither issued any comments on this possibility.

WSL executes unmodified Linux ELF64 binaries by virtualizing a Linux kernel interface on top of the Windows NT kernel. One of the kernel interfaces that it exposes are system calls (syscalls). A syscall is a service provided by the kernel that can be called from user mode. Both the Linux kernel and Windows NT kernel expose several hundred syscalls to user mode, but they have different semantics and are generally not directly compatible. For example, the Linux kernel includes things like fork, open, and kill while the Windows NT kernel has the comparable NtCreateProcess, NtOpenFile, and NtTerminateProcess.

The Windows Subsystem for Linux includes kernel mode drivers (lxss.sys and lxcore.sys) that are responsible for handling Linux system call requests in coordination with the Windows NT kernel. The drivers do not contain code from the Linux kernel but are instead a clean room implementation of Linux-compatible kernel interfaces. On native Linux, when a syscall is made from a user mode executable it is handled by the Linux kernel. On WSL, when a syscall is made from the same executable the Windows NT kernel forwards the request to lxcore.sys. Where possible, lxcore.sys translates the Linux syscall to the equivalent Windows NT call which in turn does the heavy lifting.

If you are interesting in how the Linux – Windows interaction evolves, go to Microsoft’s Blog. The team promised that more blog posts on this topic would follow.