Over the past several months, the goal of running a process, or process group, in a hardware supported virtual framework has been reached. The possibilities of what this framework can be used for are quite interesting.
Besides a security-focused isolation framework, what else could be done with this technology? One of the most interesting, in my opinion, is process migration. The current framework, with some more work, would allow a process to be seamlessly transferred from one running system to another without the user noticing any changes in their environment. Why would this be interesting? How about system upgrades without having to reboot the machine? Or moving from your home to your work computer and having your applications follow you? This only begins to enumerate the possibilities that such a fundamentally unique architecture would allow.
As a preface to all of this, we must start the discussion somewhere but in the end there are so many moving parts that it is almost arbitrary which one we describe first. As a result, there are going to be certain aspects of the discussion which we will gloss over, only to return to them in later postings. So don’t be side tracked by the direction of the discussion, we will have covered everything by the end of the series!
To start the discussion of the design itself, let’s jump into how we get the new process launched. To accomplish this task, we needed a way to start the process which we want to isolate but not have it execute beyond the process initialization in the host OS. For this we created a simple tool to launch the process but in a paused state. While it is in this state, we inject a stub DLL into the process address space and point the initial thread of the process at our entry point. This allows us to accomplish several tasks:
- Create the process that we would like to run in our framework but create it in a system-aware approach
- Establish a thread, the primary thread of the process, which will execute our shim DLL before executing any process specific code
- Introduce our shim DLL that will allow us to gain access to further control process execution within our framework
At this point in the process creation sequence, the new target application has been initialized by the system so you can bring up tools such as Task Manager and see that WinWord, for example, is a real process in the system. But we have created it in such a way that we are in control of the next steps of execution for the application.
In the next blog post, we’ll cover the aspects of initialization which we perform in our shim DLL in more detail. Stay tuned!