github.com/SagerNet/gvisor@v0.0.0-20210707092255-7731c139d75c/website/blog/2020-10-22-platform-portability.md (about) 1 # Platform Portability 2 3 Hardware virtualization is often seen as a requirement to provide an additional 4 isolation layer for untrusted applications. However, hardware virtualization 5 requires expensive bare-metal machines or cloud instances to run safely with 6 good performance, increasing cost and complexity for Cloud users. gVisor, 7 however, takes a more flexible approach. 8 9 One of the pillars of gVisor's architecture is portability, allowing it to run 10 anywhere that runs Linux. Modern Cloud-Native applications run in containers in 11 many different places, from bare metal to virtual machines, and can't always 12 rely on nested virtualization. It is important for gVisor to be able to support 13 the environments where you run containers. 14 15 gVisor achieves portability through an abstraction called a _Platform_. 16 Platforms can have many implementations, and each implementation can cover 17 different environments, making use of available software or hardware features. 18 19 ## Background 20 21 Before we can understand how gVisor achieves portability using platforms, we 22 should take a step back and understand how applications interact with their 23 host. 24 25 Container sandboxes can provide an isolation layer between the host and 26 application by virtualizing one of the layers below it, including the hardware 27 or operating system. Many sandboxes virtualize the hardware layer by running 28 applications in virtual machines. gVisor takes a different approach by 29 virtualizing the OS layer. 30 31 When an application is run in a normal situation the host operating system loads 32 the application into user memory and schedules it for execution. The operating 33 system scheduler eventually schedules the application to a CPU and begins 34 executing it. It then handles the application's requests, such as for memory and 35 the lifecycle of the application. gVisor virtualizes these interactions, such as 36 system calls, and context switching that happen between an application and OS. 37 38 [System calls](https://en.wikipedia.org/wiki/System_call) allow applications to 39 ask the OS to perform some task for it. System calls look like a normal function 40 call in most programming languages though works a bit differently under the 41 hood. When an application system call is encountered some special processing 42 takes place to do a 43 [context switch](https://en.wikipedia.org/wiki/Context_switch) into kernel mode 44 and begin executing code in the kernel before returning a result to the 45 application. Context switching may happen in other situations as well. For 46 example, to respond to an interrupt. 47 48 ## The Platform Interface 49 50 gVisor provides a sandbox which implements the Linux OS interface, intercepting 51 OS interactions such as system calls and implements them in the sandbox kernel. 52 53 It does this to limit interactions with the host, and protect the host from an 54 untrusted application running in the sandbox. The Platform is the bottom layer 55 of gVisor which provides the environment necessary for gVisor to control and 56 manage applications. In general, the Platform must: 57 58 1. Provide the ability to create and manage memory address spaces. 59 2. Provide execution contexts for running applications in those memory address 60 spaces. 61 3. Provide the ability to change execution context and return control to gVisor 62 at specific times (e.g. system call, page fault) 63 64 This interface is conceptually simple, but very powerful. Since the Platform 65 interface only requires these three capabilities, it gives gVisor enough control 66 for it to act as the application's OS, while still allowing the use of very 67 different isolation technologies under the hood. You can learn more about the 68 Platform interface in the 69 [Platform Guide](https://gvisor.dev/docs/architecture_guide/platforms/). 70 71 ## Implementations of the Platform Interface 72 73 While gVisor can make use of technologies like hardware virtualization, it 74 doesn't necessarily rely on any one technology to provide a similar level of 75 isolation. The flexibility of the Platform interface allows for implementations 76 that use technologies other than hardware virtualization. This allows gVisor to 77 run in VMs without nested virtualization, for example. By providing an 78 abstraction for the underlying platform, each implementation can make various 79 tradeoffs regarding performance or hardware requirements. 80 81 Currently gVisor provides two gVisor Platform implementations; the Ptrace 82 Platform, and the KVM Platform, each using very different methods to implement 83 the Platform interface. 84 85  86 87 The Ptrace Platform uses 88 [PTRACE\_SYSEMU](http://man7.org/linux/man-pages/man2/ptrace.2.html) to trap 89 syscalls, and uses the host for memory mapping and context switching. This 90 platform can run anywhere that ptrace is available, which includes most Linux 91 systems, VMs or otherwise. 92 93 The KVM Platform uses virtualization, but in an unconventional way. gVisor runs 94 in a virtual machine but as both guest OS and VMM, and presents no virtualized 95 hardware layer. This provides a simpler interface that can avoid hardware 96 initialization for fast start up, while taking advantage of hardware 97 virtualization support to improve memory isolation and performance of context 98 switching. 99 100 The flexibility of the Platform interface allows for a lot of room to improve 101 the existing KVM and ptrace platforms, as well as the ability to utilize new 102 methods for improving gVisor's performance or portability in future Platform 103 implementations. 104 105 ## Portability 106 107 Through the Platform interface, gVisor is able to support bare metal, virtual 108 machines, and Cloud environments while still providing a highly secure sandbox 109 for running untrusted applications. This is especially important for Cloud and 110 Kubernetes users because it allows gVisor to run anywhere that Kubernetes can 111 run and provide similar experiences in multi-region, hybrid, multi-platform 112 environments. 113 114 Give gVisor's open source platforms a try. Using a Platform is as easy as 115 providing the `--platform` flag to `runsc`. See the documentation on 116 [changing platforms](https://gvisor.dev/docs/user_guide/platforms/) for how to 117 use different platforms with Docker. We would love to hear about your experience 118 so come chat with us in our 119 [Gitter channel](https://gitter.im/gvisor/community), or send us an 120 [issue on Github](https://gvisor.dev/issue) if you run into any problems.