Shipping a Linux Kernel with Windows
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.
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.
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.
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?
Same questions here. + Will it have access to Windows filesystem like WSL1? Will the Linux kernel be running on top of NT kernel? So the devices will be controlled by NT drivers and delegated/virtualized to the Linux kernel?
So there’s going to be a Github with the stuff needed to build the kernel above/beyond whatever the kernel comes with. The kernel itself runs in a lightweight virtual mahine, I guess, and it’ll be sometime in July that we see it (they’re saying June, so figure at least one month past schedule, since it is Microsoft).
It’ll have access to the Windows File System like WSL, based on the other post.
Yes it uses Hyper-V to virtualize the address space. However its not a full VM in the traditional sense, its a light weight VM.This talk details it https://www.youtube.com/watch?v=tG8R5SQGPck&feature=youtu.be
^— Seems problematic. If it is using Hyper-V, will this preclude running WSL2 on Win10 in a VM (say, Parallels)?
Nested virtualization is a thing, so this shouldn’t be a problem. What would be a problem is running other products that don’t co-operate with an existing hypervisor (I know qemu and Virtualbox support Hyper-V’s virtualization APIs).
This comment has been deleted.
This comment has been deleted.
It certainly seems so. Along with other problems stemming from running the ‘host’ Windows machine in a VM (albeit in a root partition).