Server Silo is an OS feature that was first introduced into the Windows 10 kernel around build 17763. This feature works like Linux private namespaces, a server silo contains its own Windows environment (services, SMSS, CSRSS sub-system, WININIT, etc). It uses the host kernel and is isolated from the host silo (environment). A server silo allows redirection of resources such as the registry, network and the object manager, and each of these resources can be read-only or read-write.
For Docker, or for a security/sandboxing system. Silos provide an useful process isolation without much performance overhead compared to virtual machines, and any devices (like the GPU or the sound card) could be redirected appropriately. Nowadays, apps run in the same environment which creates a fragility: applications have an access to the whole environment, which take into account user's personal data, files and documents, they can tweak the user settings. Badly coded apps can conflict with other apps (the whole environment), and the security is pretty low. Internet browsers are often prone to attacks and 0day, if a malware escape the browser then it can put down the whole environment, this creates another fragility where an anti-virus is needed but this still doesn't solve the problem where all apps have access to the entire environment and can conflict each other.
There is a feature-request about security access for apps, issue
CORE-11548. Server silo can provide a meaningful solution to the problem.
For example apps could be grouped into multiple workspaces: one silo for all work-related apps, one silo for all personal-related apps, one silo for internet browsing, one silo for games and one silo for development environment. Host folders could be mounted into one or more workspaces (either read-only or read-write). A silo could also have its network access disabled. And it could use the host registry (read-only or read-write) or have its own registry (temporary or permanent).
In fact, a Server Silo is a special type of job object. An app first create a job object, setup the job's extended information, convert it into a silo using SetInformationJobObject (class 35), setup silo system root, tell SMSS to adopt the job, and setup various components like object manager, file system, registry, network, mount manager and named pipe. The silo can then be initialized (converted into a server silo) with SetInformationJobObject (class 40) which will create components like the USER shared data, object manager and session. The app tells SMSS about the job object to start the server silo: SMSS forks itself into the server silo and initializes all system processes inside.
Silos are part of the Windows kernel, it required some architectural changes in various components (like the process manager and the object manager). For example, the NtSetSystemPowerState() function will check if the callee's silo is the host silo (NULL), if not, it will simply terminate the server silo using PsTerminateServerSilo(). Terminating the server silo will simply terminate all processes that are part of the silo, just like a regular job object. It also required to move some of the global Process variables into a global server silo structure.
PspCatchCriticalBreak() is another example (it now has a 4th parameter instead of 3, the 4th parameter is the Silo object). If the process being terminated is part of the host silo, then it bug-checks the system, otherwise it terminates the server silo. Being part of the host silo means having a NULL silo.
Drivers can use the Silo API: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/_kernel/#silo-ddis
In 2005, Microsoft created a patent for server silos https://patents.google.com/patent/US20070134068