diff options
author | Adin Scannell <ascannell@google.com> | 2018-05-01 07:47:48 -0700 |
---|---|---|
committer | Shentubot <shentubot@google.com> | 2018-05-01 07:48:31 -0700 |
commit | 8a17bd183e0f7528c03c5445de4d74bf72e068f1 (patch) | |
tree | 6769f11004904c1822026ed67508f94f3bab1769 /README.md | |
parent | c6cd988cdc03fcb9485f6853c46c0a6c4af9c5c7 (diff) |
Make images consistent.
PiperOrigin-RevId: 194936276
Change-Id: I01f840f573c206e865de8e5e2dd4304dcb5e3621
Diffstat (limited to 'README.md')
-rw-r--r-- | README.md | 9 |
1 files changed, 4 insertions, 5 deletions
@@ -65,8 +65,6 @@ defense-in-depth. **gVisor** provides a third isolation mechanism, distinct from those mentioned above. -![gVisor](g3doc/Layers.png "gVisor") - gVisor intercepts application system calls and acts as the guest kernel, without the need for translation through virtualized hardware. gVisor may be thought of as either a merged guest kernel and VMM, or as seccomp on steroids. This @@ -75,6 +73,8 @@ on threads and memory mappings, not fixed guest physical resources) while also lowering the fixed costs of virtualization. However, this comes at the price of reduced application compatibility and higher per-system call overhead. +![gVisor](g3doc/Layers.png "gVisor") + On top of this, gVisor employs rule-based execution to provide defense-in-depth (details below). @@ -106,8 +106,6 @@ application to directly control the system calls it makes. ### File System Access -![Sentry](g3doc/Sentry-Gofer.png "Sentry and Gofer") - In order to provide defense-in-depth and limit the host system surface, the gVisor container runtime is normally split into two separate processes. First, the *Sentry* process includes the kernel and is responsible for executing user @@ -115,6 +113,8 @@ code and handling system calls. Second, file system operations that extend beyon the sandbox (not internal proc or tmp files, pipes, etc.) are sent to a proxy, called a *Gofer*, via a 9P connection. +![Sentry](g3doc/Sentry-Gofer.png "Sentry and Gofer") + The Gofer acts as a file system proxy by opening host files on behalf of the application, and passing them to the Sentry process, which has no host file access itself. Furthermore, the Sentry runs in an empty user namespace, and the @@ -228,7 +228,6 @@ Terminal support works too: docker run --runtime=runsc -it ubuntu /bin/bash ``` - ### Kubernetes Support (Experimental) gVisor can run sandboxed containers in a Kubernetes cluster with cri-o, although |