r-mode binary ntdll.dll is not mapped into the process by default.
The process environment block (PEB) is not created.
There is no initial thread created, and thread environment blocks (TEBs) are not automatically created whenever a thread is created for the pico process.
The shared user data section is not mapped into the process. This is a block of memory mapped read-only into all user-mode address space for efficient retrieva l of common system-wide information.
Various places that assumed a process would always have a PEB and/or TEBs were updated to be able to handle processes without them.
While the Windows kernel does not actively manage a minimal process, it still provides all of the underlying OS support you would expect – thread scheduling, memory management, etc.
You may be wondering – why did we separate the notion of “minimal” and “pico” processes? The idea of an empty minimal process seemed useful on its own, separate from anything related to supporting a pico process. While we had nothing specific in mind around this time back in 2013, eventually a couple of scenarios did surface in Windows 10 that are now using minimal processes directly:
- Memory Compression: Memory compression is a Windows feature that compresses unused memory to keep more data resident in RAM. It also reduces the amount of data written to and read from the pagefile, thus improving performance. Windows memory compression utilizes the user-mode address space of a minimal process.
- Virtualization based Security (VBS): Using underlying virtualization capabilities, VBS isolates the user-mode address space of critical user-mode processes from the rest of the OS to prevent tampering, even from the kernel or kernel-mode drivers. A minimal process is created to indicate to management tools (e.g., Task Manager) that VBS is running.
Pico Processes and Providers
A pico process is simply a minimal process that is associated with a pico provider kernel-mode driver. This pico provider surfaces the entire kernel interface as far as the user-mode portion of the process is concerned. The Windows kernel passes all system calls and exceptions that originate from the user-mode portion of a pico process to the pico provider to handle as it sees fit. This allows the pico provider to model a different user/kernel contract separate from what Windows would normally provide.
Early during boot, a kernel-mode driver registers with the Windows kernel as a pico provider, and the kernel and provider exchange a set of interfaces specific to the needs of a pico provider. For example, the pico provider provides function pointers for the kernel to call when dispatching a user-mode system call or exception, and the kernel provides function pointers for creating pico processes and threads.
Regardless of what behaviors and abstractions the pico provider exposes to user-mode, it ultimately will rely on the Windows kernel for underlying support of thread scheduling, memory management and I/O. Of course, portions of the Windows kernel had to be updated to support new scenarios where needed.
Windows Kernel Changes
Later posts will detail the Windows kernel changes in more detail, but here is a quick sampling:
- Improved fork support: Yes – the Windows kernel has supported “fork” for a long time (going back to earlier POSIX and SFU application support), but it is not exposed in the Win32 programming model that the rest of Windows is programmed against. We have improved the fork implementation to meet some new requirements as pa