Shipping a Linux Kernel with Windows

Jack Hammons

Jack

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 Kernel.org, 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.

Security

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.

Thanks!

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.

Jack Hammons
Jack Hammons

Program Manager, Linux Systems Group

Follow Jack   

21 Comments
Avatar
Giovanni Bassi 2019-05-06 14:13:32
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
Fred Miller 2019-05-06 17:42:31
So... are we finally getting systemd running on WSL?
Avatar
Cloud Han 2019-05-06 18:25:27
Is it possible to run cuda enabled application with WSL2?
Avatar
Денис Седченко 2019-05-07 06:41:51
If WSL will use Hyper-V, that means that I can't use other hypervisors at the same time, am I right?
Avatar
Vasiliy Novikov 2019-05-07 07:25:39
Does it mean that it will be able to run custom linux kernel modules?
Avatar
Pedro Giffuni 2019-05-07 08:03:42
If I read this correctly, the move to a VM and a custom kernel would make it posible to run other non-linux kernels like FreeBSD, which is also available on Azure, natively on Windows. Really cool!
Avatar
Jan Klos 2019-05-07 09:18:35
So basically just a Hyper-V-based Linux VM with customized kernel. Hyper-V => other virtualization providers do not work. That's a real bummer...I hope you will continue to support WSL1, then.
Avatar
Abey Thomas Raju 2019-05-07 20:33:08
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
Chris Palmer 2019-05-08 16:21:58
My major issue with WSL is that I can't see my GPU, will WSL2 fix this - for instance will it allow nvidia-docker to run and expose my GPU?
Avatar
RB 2019-05-10 10:34:33
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 2019-05-10 19:26:33
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
Lars Hasselrot 2019-05-14 05:28:02
What, if anything, does this mean for running linux containers on windows?