summaryrefslogtreecommitdiffhomepage
path: root/README.md
diff options
context:
space:
mode:
authorAdin Scannell <ascannell@google.com>2018-05-01 07:47:48 -0700
committerShentubot <shentubot@google.com>2018-05-01 07:48:31 -0700
commit8a17bd183e0f7528c03c5445de4d74bf72e068f1 (patch)
tree6769f11004904c1822026ed67508f94f3bab1769 /README.md
parentc6cd988cdc03fcb9485f6853c46c0a6c4af9c5c7 (diff)
Make images consistent.
PiperOrigin-RevId: 194936276 Change-Id: I01f840f573c206e865de8e5e2dd4304dcb5e3621
Diffstat (limited to 'README.md')
-rw-r--r--README.md9
1 files changed, 4 insertions, 5 deletions
diff --git a/README.md b/README.md
index b7e2c6902..01830eb3a 100644
--- a/README.md
+++ b/README.md
@@ -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