WSL 2 runs a real Linux kernel inside a lightweight utility VM, and each distribution runs as an isolated container inside it. Distros share the kernel, memory, network namespace and some other resources. They keep their own process, mount, user and cgroup namespaces. It is not a hard boundary between your distros.
The architecture in Microsoft's words
Microsoft says WSL 2 uses virtualisation technology to run a Linux kernel inside a lightweight utility VM. Linux distributions run as isolated containers inside the WSL 2 managed VM.
Distributions running through WSL 2 share:
- The network namespace.
- The device tree, other than /dev/pts.
- CPU, kernel, memory and swap.
- The /init binary.
They each have their own:
- PID namespace.
- Mount namespace.
- User namespace.
- Cgroup namespace.
- Init process.
Reading that for security
Sharing a kernel and network namespace means two distros are not strangers to each other. If you install an untrusted tool in one distro, treat the others in the same WSL 2 VM as exposed to a kernel-level problem. If you need a harder boundary, use a separate VM or a disposable environment, and see the post on Windows Sandbox.
Separate namespaces still give you real separation of processes, mounts and users between distros. They are not nothing.
Files
Microsoft says WSL lets you store files in an isolated Linux file system specific to the installed distribution. That is the safer home for repositories you work on from Linux.
The Dev Drive documentation adds a note on the crossing point. Project files on a Windows volume can be reached from a distro, but for performance, files should live on the Linux file system. The WSL metadata mount option, which stores Linux permissions on Windows-hosted files, is not supported on ReFS volumes such as Dev Drive.
Practical effect: where files live decides which operating system's permission model protects them.
You can invoke Windows from Linux
The WSL overview says you can invoke Windows applications from a Unix-like shell, and Linux applications on Windows. That integration is a convenience, and it is also a path between the two worlds. Think about it when you run scripts you did not write.
A sensible setup
- Keep one distro for trusted daily work.
- Use a separate distro, or better a separate disposable environment, for code you do not trust.
- Keep repositories on the Linux file system.
- Update the distro with its package manager as you would any Linux machine, since Microsoft notes you use your own distribution's package manager for added software.
- Do not store tokens in files that both sides can read.
What this post cannot tell you
The pages used here do not describe how to disable Windows interop or restrict drive mounting. Look for those settings in Microsoft's current WSL configuration documentation before relying on them.
Quick check
Do two WSL 2 distros share a kernel?
Yes. Microsoft says distributions share the CPU, kernel, memory and swap, and the network namespace.
Do they share a process list?
No. Each distribution has its own PID namespace and init process.
Sources
- What is Windows Subsystem for Linux (Microsoft Learn)
- Set up a Dev Drive on Windows 11 (Microsoft Learn)
Last reviewed: 19 October 2026.
