In this blog, I am going to pen down my first experiment with Windows Subsystem for Linux where I virtualized WSL's launcher component. I'll start with summarizing my WSL learning (with links to Microsoft's site) and then take you through the setup and how I ended up virtualizing WSL launcher. I am yet to analyse it fully, so I'll be posting followup blogs as I move on with my experiments. I would really like to get feedback from those who experimented with WSL earlier. I've used tools like APIMonitor, WinDbg, ProcessHacker and Cloudhouse's Virtualization engine while trying these experiments.
Getting Acquainted with WSL
I started exploring WSL components and digging into its details. Channel 9 videos were very useful in understanding the concepts. Also, Jessie Frazelle's blog is a good read too. Please do watch Channel9 videos to understand this whole concept. I've summarized WSL's key points in tech fundamental's article "WSL in a Nutshell". After getting some idea on WSL I started setting up my Win10 VM, enabled WSL feature and setup Ubuntu distribution on it (here is the guide).
WSL Dissection
I first launched WSL from a command prompt (by running wsl). Then launched Ubuntu desktop app, which in-turn spawned wsl.exe. In both the cases, as soon as wsl is invoked, the WSL launcher instantiates a COM instance with LxssUserSession's CLSID. This is handled by the LXCore kernel module which then starts a PICO process "init" under svchost. The init process remains alive as long as any of the wsl processes are running. Here is the process snapshot.
As seen in the pic (marked with RED boxes), whether you launch a Linux distribution app (like Ubuntu) or directly start WSL from the command prompt, it starts WSL launcher which triggers ioctl calls and "init" is spawned. When you run any command under the WSL prompt (like bash, vi etc.), init forks out a new process like "bash", "vim.basic" (seen in the pic below).
Init, bash, vim are not normal Win32 processes, they are the PICO processes which only LXCore/LXSS driver can understand. Here is a diagram published on Microsoft website which gives a good idea on how these processes fit into WSL architecture.
While trying out various commands, I took APIMonitor trace to look at all the calls made by the WSL Launcher; the Win APIs invoked and the response it gets back for those calls.
Tip : If you are not aware of APIMonitor, then check it out here. Its one of the best open source tools to monitor and control calls from processes and services running on Windows.
Tip : If you are not aware of APIMonitor, then check it out here. Its one of the best open source tools to monitor and control calls from processes and services running on Windows.
The Uncharted Waters!
Being a virtualization developer, my first attempt was to virtualize the WSL Launcher itself. So, I used our virtualization engine to hook into the WSL launcher process and it worked! I was able to monitor calls made by WSL launcher from the moment it started until its lifetime.
APIMonitor trace is also very useful to see what's going on under the hood. I am yet to anlayze these in detail. There are few interesting actions triggered by wsl launcher for configuration, networking calls, COM object creation etc. Most interesting part is when it instantiates LxssUserSession COM object (which will be my next attempt). Also, I am planning to experiment more by imposing network redirections, virtualizing its COM calls, tweaking configuration settings etc. I am not sure what these will end up in, but l am optimistic that something useful will come out of my experiments. My ultimate aim is to virtualize the Lxss Session Manager and dig into nitty-gritty of how it controls Linux instances. This is a totally weird thought at the moment. Also, it will be interesting to work with PICO processes, which are alien to Windows OS itself, which only LxCore understands.
Signing off for now. I'll work on it next week (if I get time) and update my findings in the Geeky Corner.
Priya Saxena.
No comments:
Post a Comment