Shipping a Linux Kernel with Windows

Jack Hammons


Beginning with Windows Insiders builds this Summer, we will include an in-house custom-built Linux kernel to underpin the newest version of the Windows Subsystem for Linux (WSL). This marks the first time that the Linux kernel will be included as a component in Windows. This is an exciting day for all of us on the Linux team at Microsoft and we are thrilled to be able to tell you a little bit about it.

Tuned for WSL

The term “Linux” is often used to refer both to the Linux kernel as well as the GNU userspace. As with WSL1, WSL2 will not provide any userspace binaries. Instead, the Microsoft kernel will interface with a userspace selected by the user. This will generally come through installation via the Windows store but can also be “sideloaded” through the creation of a custom distribution package. The only exception to this rule is a small init script that is injected to bootstrap the startup process, forming the connections between Windows and Linux that make WSL so magical.

The kernel itself will initially be based on version 4.19, the latest long-term stable release of Linux. The kernel will be rebased at the designation of new long-term stable releases to ensure that the WSL kernel always has the latest Linux goodness.

In addition to the LTS source from, a number of local patches are being applied. These patches tune the resulting binary for use in WSL2 by improving launch times, reducing the memory footprint and curating a minimal set of supported devices. The result is a small, lightweight kernel that is purpose built for WSL2 to be a drop-in replacement for the emulation architecture featured in the design of WSL1.

Code goes upstream

Microsoft employs a growing number of Linux contributors who have brought industry leading Linux knowhow into the company. For years now, these Linux developers have enabled Microsoft to support new platform features in the wide number of distributions provided in the Azure Marketplace.

An important philosophy of Linux at Microsoft is that all changes go upstream. Maintaining downstream patches adds complexity and is not standard practice in the open source community. In leveraging Linux, we are making a commitment to be good citizens and contribute back the changes that we make.

However, during development it is necessary to work with local patches that enable new features or address issues in upstream. In these cases, we either create, or find patches that fulfill our product requirements and then work with the community to get that code integrated as soon as possible. To protect the stability of the LTS branches, some patches – such as for new features – might only be included in future versions of the kernel, and not be back-ported to the current LTS version.

When the WSL kernel source becomes available it will consist of links to a set of patches in addition to the long-term stable source. Over time, we hope this list will shrink as patches make it upstream and grow as we add new local patches to support new WSL features.


The WSL kernel will be built using Microsoft’s world-class CI/CD systems and serviced through Windows Update in an operation transparent to the user. The kernel will stay up to date with the newest features and fixes in the latest stable branch of Linux. To ensure the provenance of our sources we mirror repositories locally. We continually monitor Linux security mailing lists and partner with several CVE database companies to help ensure that our kernel has the most recent fixes and mitigations.

One of the great things about Linux is its stable and backwards compatible system call interface. This will enable us to ship the latest stable branch of the Linux kernel to all versions of WSL2. We will rebase the kernel when a new LTS is established and when we have sufficiently validated it.

Open Source

The kernel provided for WSL2 will be fully open source! When WSL2 is released in Windows Insider builds, instructions for creating your own WSL kernel will be made available on Github. We will work with developers interested in contributing to help get changes upstream. Check back in a few weeks for more information.


This is the culmination of years of effort from the Linux Systems Group as well as multiple other teams across Microsoft. We are excited to be able to share the result and look forward to the new and interesting ways in which you will use WSL. If you are interested in positions at Microsoft working with Linux check out this job listing.


Leave a comment

  • Avatar
    Giovanni Bassi

    How are you going to run this kernel? Is it going to be virtualized in some way, using Hyper V technologies? Are you creating full VM that will be started or stopped? Will this kernel delegate anything to the Windows Kernel? If not, how are working so they can share the hardware?

    • Avatar
      Ken Clark

      Most probably. WSL1 is pretty close to being able to run systemd as it is. Depends a bit on how they are doing the network bridge; it isn’t clear whether their modified Linux kernel is running the Linux ipv4/ipv6 stack and they are going to tunnel at the ethernet layer, or whether they are passing socket calls through to the Windows ip stack. Also depends on whether they are doing NETLINK_KOBJECT_UEVENT. But even if we don’t get those (or not right away), the “full system call compatibility” mention in the Craig’s WSL2 announcement blog post should be enough to get systemd running. So short answer, yes.

  • Avatar
    Abey Thomas Raju

    This is interesting. I would be like to know how does this practically work with docker containers. Can I take a Linux docker image and run it on a windows docker engine natively without the the docker engine using hyper-v/linux vm under the hoods? Any links on this is appreciated.. 

  • Avatar

    Why don’t you use the FreeBSD Kernel instead? You should investigate it.

    It is much cleaner, extremely consistent, well architected and has a neat Linux Binary Compatibility Layer.

    You would have the best of both worlds, and interesting perks such as jails and excellent native ZFS support.

  • Avatar
    Bari Pishdadi

    Hola, Hello, Hi everyone.

    @Jack – I’m hopeful that the decisions your team makes aren’t all predicated on the “drive profit / the bottom-line first” mentality that has propelled MS for the last 40 years. We want cheaper computing including license free software like UNIX/LINUX, so well done on the linux integration. Putting my technical ignorance aside for a moment, I wanted to present a use-case scenario to you. Supposing there is an ARM and/or Intel based windows10 machine with SIM card integration. Can an instance of a linux enviroment get access to one hardware device/radio (wifi/sim) at the same time as the windows environment uses the other device/radio (sim/WIFI). For whatever reason, assuming traffic needed to be segregated. Am I too far ahead of myself assuming that since you’re baking linux into the OS, I could have my son boot up into a version of EDUBUNTU and have two OS’s running side by side?Is the talk of Windows Terminal just a GUI command line interface into servers, primarily aimed at server adminstrators or is this creating a new environment within Windows?Lots of questions. Thanks. And well done on the Build Interview

  • Avatar
    Kenneth Benson

    Here are 2 scenarios I need to know about. I have an InfiniteNoise USB stick(basically a true random number generator). The way the interface is implemented is bit-banging USB ports on the stick. WSL 1 can’t see or touch it. Will WSL 2 be able to work with it(Linux libusb is used)?

    2nd scenario, I’m doing some work with Deep Learning operating against an Nvidia GTX-1050 Ti using Cuda on Linux. I need to if WSL 2 will be able to use the Linux Cuda drivers to continue that work.

    At present I have a system with 3 seperate TB drives, 2 set up in Windows and the 3rd separately bootable to a Debian distribution. I would love to not have to reboot every time and use a USB 64GB stick to transfer data back and forth.