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