summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
-rw-r--r--README.md14
1 files changed, 7 insertions, 7 deletions
diff --git a/README.md b/README.md
index e5fc31ac8..092172465 100644
--- a/README.md
+++ b/README.md
@@ -45,7 +45,7 @@ performance (though nested virtualization may bring challenges in this area),
but for containers it often requires additional proxies and agents, and may
require a larger resource footprint and slower start-up times.
-<p align="center"><img src="g3doc/Machine-Virtualization.png"></p>
+![Machine-level virtualization](g3doc/Machine-Virtualization.png "Machine-level virtualization")
**Rule-based execution**, such as [seccomp][seccomp], [SELinux][selinux] and
[AppArmor][apparmor], allows the specification of a fine-grained security policy
@@ -57,14 +57,16 @@ However, in practice it can be extremely difficult (if not impossible) to
reliably define a policy for arbitrary, previously unknown applications,
making this approach challenging to apply universally.
+![Rule-based execution](g3doc/Rule-Based-Execution.png "Rule-based execution")
+
Rule-based execution is often combined with additional layers for
defense-in-depth.
-<p align="center"><img src="g3doc/Rule-Based-Execution.png"></p>
-
**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
@@ -76,8 +78,6 @@ reduced application compatibility and higher per-system call overhead.
On top of this, gVisor employs rule-based execution to provide defense-in-depth
(details below).
-<p align="center"><img src="g3doc/Layers.png"></p>
-
gVisor's approach is similar to [User Mode Linux (UML)][uml], although UML
virtualizes hardware internally and thus provides a fixed resource footprint.
@@ -106,6 +106,8 @@ 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
@@ -119,8 +121,6 @@ access itself. Furthermore, the Sentry runs in an empty user namespace, and the
system calls made by gVisor to the host are restricted using seccomp filters in
order to provide defense-in-depth.
-<p align="center"><img src="g3doc/Sentry-Gofer.png"></p>
-
### Network Access
The Sentry implements its own network stack (also written in Go) called