Merge branch 'master' into readme

10 files changed, 57 insertions, 66 deletions

diff --git a/content/docs/architecture_guide/_index.md b/content/docs/architecture_guide/_index.md
index 63842caa4..81c128464 100644
--- a/content/docs/architecture_guide/_index.md
+++ b/content/docs/architecture_guide/_index.md
@@ -72,8 +72,6 @@ race detector. (The use of Go has its challenges too, and isn't free.)
 [apparmor]: https://wiki.ubuntu.com/AppArmor
 [golang]: https://golang.org
 [kvm]: https://www.linux-kvm.org
-[oci]: https://www.opencontainers.org
-[sandbox]: https://en.wikipedia.org/wiki/Sandbox_(computer_security)
 [seccomp]: https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt
 [selinux]: https://selinuxproject.org
 [uml]: http://user-mode-linux.sourceforge.net/
diff --git a/content/docs/architecture_guide/security.md b/content/docs/architecture_guide/security.md
index 93723727c..70c54bf95 100644
--- a/content/docs/architecture_guide/security.md
+++ b/content/docs/architecture_guide/security.md
@@ -32,9 +32,9 @@ are written in [C][clang], which is well-suited to interfacing with hardware but
 often prone to security issues. In order to exploit these issues, a typical attack
 might involve some combination of the following:
 
- 1. Opening or creating some combination of files, sockets or other descriptors.
- 1. Passing crafted, malicious arguments, structures or packets.
- 1. Racing with multiple threads in order to hit specific code paths.
+1. Opening or creating some combination of files, sockets or other descriptors.
+1. Passing crafted, malicious arguments, structures or packets.
+1. Racing with multiple threads in order to hit specific code paths.
 
 For example, for the [Dirty Cow][dirtycow] privilege escalation bug, an
 application would open a specific file in `/proc` or use a specific `ptrace`
@@ -140,15 +140,15 @@ filesystem attributes) and not underlying host system resources.
 While the sandbox virtualizes many operations for the application, we limit the
 sandbox's own interactions with the host to the following high-level operations:
 
- 1. Communicate with a Gofer process via a connected socket. The sandbox may
-    receive new file descriptors from the Gofer process, corresponding to opened
-    files. These files can then be read from and written to by the sandbox.
- 1. Make a minimal set of host system calls. The calls do not include the
-    creation of new sockets (unless host networking mode is enabled) or opening
-    files. The calls include duplication and closing of file descriptors,
-    synchronization, timers and signal management.
- 1. Read and write packets to a virtual ethernet device. This is not required if
-    host networking is enabled (or networking is disabled).
+1. Communicate with a Gofer process via a connected socket. The sandbox may
+   receive new file descriptors from the Gofer process, corresponding to opened
+   files. These files can then be read from and written to by the sandbox.
+1. Make a minimal set of host system calls. The calls do not include the
+   creation of new sockets (unless host networking mode is enabled) or opening
+   files. The calls include duplication and closing of file descriptors,
+   synchronization, timers and signal management.
+1. Read and write packets to a virtual ethernet device. This is not required if
+   host networking is enabled (or networking is disabled).
 
 ### System ABI, Side Channels and Other Vectors
 
@@ -173,32 +173,32 @@ less likely to exploit or override these controls through other means.
 For gVisor development, there are several engineering principles that are
 employed in order to ensure that the system meets its design goals.
 
- 1. No system call is passed through directly to the host. Every supported call
-    has an independent implementation in the Sentry, that is unlikely to suffer
-    from identical vulnerabilities that may appear in the host. This has the
-    consequence that all kernel features used by applications require an
-    implementation within the Sentry.
- 1. Only common, universal functionality is implemented. Some filesystems,
-    network devices or modules may expose specialized functionality to user
-    space applications via mechanisms such as extended attributes, raw sockets
-    or ioctls. Since the Sentry is responsible for implementing the full system
-    call surface, we do not implement or pass through these specialized APIs.
- 1. The host surface exposed to the Sentry is minimized. While the system call
-    surface is not trivial, it is explicitly enumerated and controlled. The
-    Sentry is not permitted to open new files, create new sockets or do many
-    other interesting things on the host.
+1. No system call is passed through directly to the host. Every supported call
+   has an independent implementation in the Sentry, that is unlikely to suffer
+   from identical vulnerabilities that may appear in the host. This has the
+   consequence that all kernel features used by applications require an
+   implementation within the Sentry.
+1. Only common, universal functionality is implemented. Some filesystems,
+   network devices or modules may expose specialized functionality to user
+   space applications via mechanisms such as extended attributes, raw sockets
+   or ioctls. Since the Sentry is responsible for implementing the full system
+   call surface, we do not implement or pass through these specialized APIs.
+1. The host surface exposed to the Sentry is minimized. While the system call
+   surface is not trivial, it is explicitly enumerated and controlled. The
+   Sentry is not permitted to open new files, create new sockets or do many
+   other interesting things on the host.
 
 Additionally, we have practical restrictions that are imposed on the project to
 minimize the risk of Sentry exploitability. For example:
 
- 1. Unsafe code is carefully controlled. All unsafe code is isolated in files
-    that end with "unsafe.go", in order to facilitate validation and auditing.
-    No file without the unsafe suffix may import the unsafe package.
- 1. No CGo is allowed. The Sentry must be a pure Go binary.
- 1. External imports are not generally allowed within the core packages. Only
-    limited external imports are used within the setup code. The code available
-    inside the Sentry is carefully controlled, to ensure that the above rules
-    are effective.
+1. Unsafe code is carefully controlled. All unsafe code is isolated in files
+   that end with "unsafe.go", in order to facilitate validation and auditing.
+   No file without the unsafe suffix may import the unsafe package.
+1. No CGo is allowed. The Sentry must be a pure Go binary.
+1. External imports are not generally allowed within the core packages. Only
+   limited external imports are used within the setup code. The code available
+   inside the Sentry is carefully controlled, to ensure that the above rules
+   are effective.
 
 Finally, we recognize that security is a process, and that vigilance is
 critical. Beyond our security disclosure process, the Sentry is fuzzed
diff --git a/content/docs/community/_index.md b/content/docs/community/_index.md
index ed02c8bdc..0f493c15a 100644
--- a/content/docs/community/_index.md
+++ b/content/docs/community/_index.md
@@ -9,8 +9,8 @@ repositories have their own guidelines and processes for contributing. See the
 
 The project maintains two mailing lists:
 
- * [gvisor-users][gvisor-users] for accouncements and general discussion.
- * [gvisor-dev][gvisor-dev] for development and contribution.
+* [gvisor-users][gvisor-users] for accouncements and general discussion.
+* [gvisor-dev][gvisor-dev] for development and contribution.
  
 We also have a [chat room hosted on Gitter][gitter-chat].
 
diff --git a/content/docs/tutorials/docker.md b/content/docs/tutorials/docker.md
index 8391515c3..d39b514c6 100644
--- a/content/docs/tutorials/docker.md
+++ b/content/docs/tutorials/docker.md
@@ -59,7 +59,7 @@ docker run --runtime=runsc --name wordpress -d \
 ```
 
 Now, you can access the WordPress website pointing your favorite browser to
-http://localhost:8080.
+<http://localhost:8080>.
 
 Congratulations! You have just deployed a WordPress site using Docker.
 
diff --git a/content/docs/user_guide/checkpoint_restore.md b/content/docs/user_guide/checkpoint_restore.md
index bbc08a5f2..fef4c1dfa 100644
--- a/content/docs/user_guide/checkpoint_restore.md
+++ b/content/docs/user_guide/checkpoint_restore.md
@@ -20,7 +20,7 @@ file will be called `checkpoint.img` and necessary directories will be created
 if they do not yet exist.
 
 > Note: Two checkpoints cannot be saved to the same directory; every image-path
-provided must be unique.
+> provided must be unique.
 
 ```bash
 runsc checkpoint --image-path=<path> <container id>
@@ -31,11 +31,11 @@ continue to run after the checkpoint has been made. (By default, containers stop
 their processes after committing a checkpoint.)
 
 > Note: All top-level runsc flags needed when calling run must be provided to
-checkpoint if --leave-running is used.
+> checkpoint if --leave-running is used.
 
 > Note: --leave-running functions by causing an immediate restore so the
-container, although will maintain its given container id, may have a different
-process id.
+> container, although will maintain its given container id, may have a different
+> process id.
 
 ```bash
 runsc checkpoint --image-path=<path> --leave-running <container id>
diff --git a/content/docs/user_guide/debugging.md b/content/docs/user_guide/debugging.md
index 4d26d557c..49f9638d7 100644
--- a/content/docs/user_guide/debugging.md
+++ b/content/docs/user_guide/debugging.md
@@ -106,9 +106,9 @@ Then restart docker to refresh the runtime options. While the container is runni
 execute `runsc debug` to collect profile information and save to a file. Here are
 the options available:
 
- * **--profile-heap:** Generates heap profile to the speficied file.
- * **--profile-cpu:** Enables CPU profiler, waits for `--profile-delay` seconds 
-   and generates CPU profile to the speficied file.
+* **--profile-heap:** Generates heap profile to the speficied file.
+* **--profile-cpu:** Enables CPU profiler, waits for `--profile-delay` seconds 
+  and generates CPU profile to the speficied file.
 
 For example:
 
@@ -120,7 +120,7 @@ sudo runsc --root /var/run/docker/runtime-runsc-prof/moby debug --profile-heap=/
 sudo runsc --root /var/run/docker/runtime-runsc-prof/moby debug --profile-cpu=/tmp/cpu.prof --profile-delay=30 63254c6ab3a6989623fa1fb53616951eed31ac605a2637bb9ddba5d8d404b35b
 ```
 
-The resulting files can be opened using `go tool pprof` or [pprof]. The examples 
+The resulting files can be opened using `go tool pprof` or [pprof][]. The examples 
 below create image file (`.svg`) with the heap profile and writes the top 
 functions using CPU to the console:
 
diff --git a/content/docs/user_guide/install.md b/content/docs/user_guide/install.md
index a76383b06..f25bc0d73 100644
--- a/content/docs/user_guide/install.md
+++ b/content/docs/user_guide/install.md
@@ -101,10 +101,10 @@ curl -fsSL https://gvisor.dev/archive.key | sudo apt-key add -
 Based on the release type, you will need to substitute `${DIST}` below, using
 one of:
 
- * `master`: For HEAD.
- * `nightly`: For nightly releases.
- * `release`: For the latest release.
- * `${yyyymmdd}`: For a specific releases (see above).
+* `master`: For HEAD.
+* `nightly`: For nightly releases.
+* `release`: For the latest release.
+* `${yyyymmdd}`: For a specific releases (see above).
 
 The repository for the release you wish to install should be added:
 
@@ -158,12 +158,5 @@ optionally automatically configure Docker:
 runsc install
 ```
 
-[latest-nightly]: https://storage.googleapis.com/gvisor/releases/nightly/latest/runsc
-
-[latest-hash]: https://storage.googleapis.com/gvisor/releases/nightly/latest/runsc.sha512
-
-[oci]: https://www.opencontainers.org
-
 [old-linux]: /docs/user_guide/networking/#gso
-
 [releases]: https://github.com/google/gvisor/releases
diff --git a/content/docs/user_guide/platforms.md b/content/docs/user_guide/platforms.md
index e15072068..b0b76c0ee 100644
--- a/content/docs/user_guide/platforms.md
+++ b/content/docs/user_guide/platforms.md
@@ -58,10 +58,10 @@ If you are using a virtual machine you will need to make sure that nested
 virtualization is configured. Here are links to documents on how to set up
 nested virtualization in several popular environments:
 
- * Google Cloud: [Enabling Nested Virtualization for VM Instances][nested-gcp]
- * Microsoft Azure: [How to enable nested virtualization in an Azure VM][nested-azure]
- * VirtualBox: [Nested Virtualization][nested-virtualbox]
- * KVM: [Nested Guests][nested-kvm]
+* Google Cloud: [Enabling Nested Virtualization for VM Instances][nested-gcp]
+* Microsoft Azure: [How to enable nested virtualization in an Azure VM][nested-azure]
+* VirtualBox: [Nested Virtualization][nested-virtualbox]
+* KVM: [Nested Guests][nested-kvm]
 
 ### Configuring Docker
 
diff --git a/content/docs/user_guide/quick_start/_index.md b/content/docs/user_guide/quick_start/_index.md
index 770fd8893..3d1524bc8 100644
--- a/content/docs/user_guide/quick_start/_index.md
+++ b/content/docs/user_guide/quick_start/_index.md
@@ -7,6 +7,6 @@ gVisor can be used with Docker, Kubernetes, or directly using `runsc` with
 crafted OCI spec for your container. Use the links below to see detailed
 instructions for each of them:
 
- * [Docker](./docker/): The quickest and easiest way to get started.
- * [Kubernetes](./kubernetes/): Isolate Pods in your K8s cluster with gVisor.
- * [OCI](./oci/): Expert mode. Customize gVisor for your environment.
+* [Docker](./docker/): The quickest and easiest way to get started.
+* [Kubernetes](./kubernetes/): Isolate Pods in your K8s cluster with gVisor.
+* [OCI](./oci/): Expert mode. Customize gVisor for your environment.
diff --git a/content/docs/user_guide/quick_start/kubernetes.md b/content/docs/user_guide/quick_start/kubernetes.md
index b3b5e0a55..e21abbc70 100644
--- a/content/docs/user_guide/quick_start/kubernetes.md
+++ b/content/docs/user_guide/quick_start/kubernetes.md
@@ -36,4 +36,4 @@ WordPress site. You can view the full documentation [here][gke-sandbox-docs].
 [gke-sandbox-docs]: https://cloud.google.com/kubernetes-engine/docs/how-to/sandbox-pods
 [gvisor-containerd-shim]: https://github.com/google/gvisor-containerd-shim
 [runtimeclass]: https://kubernetes.io/docs/concepts/containers/runtime-class/
-[wordpress-quick]: /docs/tutorials/kubernetes/
\ No newline at end of file
+[wordpress-quick]: /docs/tutorials/kubernetes/