1 files changed, 60 insertions, 60 deletions
diff --git a/g3doc/architecture_guide/security.md b/g3doc/architecture_guide/security.md
index afafe5c05..f78586291 100644
--- a/g3doc/architecture_guide/security.md
+++ b/g3doc/architecture_guide/security.md
@@ -27,14 +27,14 @@ namespaces.
 
 Although the System API is exposed to applications by design, bugs and race
 conditions within the kernel or hypervisor may occasionally be exploitable via
-the API. This is common in part due to the fact that most kernels and hypervisors
-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:
+the API. This is common in part due to the fact that most kernels and
+hypervisors 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`
@@ -74,8 +74,8 @@ hyperthread.
 
 The above categories in no way represent an exhaustive list of exploits, as we
 focus only on running untrusted code from within the operating system or
-hypervisor.  We do not consider other ways that a more generic adversary
-may interact with a system, such as inserting a portable storage device with a
+hypervisor. We do not consider other ways that a more generic adversary may
+interact with a system, such as inserting a portable storage device with a
 malicious filesystem image, using a combination of crafted keyboard or touch
 inputs, or saturating a network device with ill-formed packets.
 
@@ -100,30 +100,30 @@ The first principle is similar to the security basis for a Virtual Machine (VM).
 With a VM, an application’s interactions with the host are replaced by
 interactions with a guest operating system and a set of virtualized hardware
 devices. These hardware devices are then implemented via the host System API by
-a Virtual Machine Monitor (VMM). The Sentry similarly prevents direct interactions
-by providing its own implementation of the System API that the application
-must interact with. Applications are not able to to directly craft specific
-arguments or flags for the host System API, or interact directly with host
-primitives.
+a Virtual Machine Monitor (VMM). The Sentry similarly prevents direct
+interactions by providing its own implementation of the System API that the
+application must interact with. Applications are not able to to directly craft
+specific arguments or flags for the host System API, or interact directly with
+host primitives.
 
 For both the Sentry and a VMM, it’s worth noting that while direct interactions
 are not possible, indirect interactions are still possible. For example, a read
 on a host-backed file in the Sentry may ultimately result in a host read system
-call (made by the Sentry, not by passing through arguments from the application),
-similar to how a read on a block device in a VM may result in the VMM issuing
-a corresponding host read system call from a backing file.
-
-An important distinction from a VM is that the Sentry implements a System API based
-directly on host System API primitives instead of relying on virtualized hardware
-and a guest operating system. This selects a distinct set of trade-offs, largely
-in the performance, efficiency and compatibility domains. Since transitions in
-and out of the sandbox are relatively expensive, a guest operating system will
-typically take ownership of resources. For example, in the above case, the
-guest operating system may read the block device data in a local page cache,
-to avoid subsequent reads. This may lead to better performance but lower
-efficiency, since memory may be wasted or duplicated. The Sentry opts instead
-to defer to the host for many operations during runtime, for improved efficiency
-but lower performance in some use cases.
+call (made by the Sentry, not by passing through arguments from the
+application), similar to how a read on a block device in a VM may result in the
+VMM issuing a corresponding host read system call from a backing file.
+
+An important distinction from a VM is that the Sentry implements a System API
+based directly on host System API primitives instead of relying on virtualized
+hardware and a guest operating system. This selects a distinct set of
+trade-offs, largely in the performance, efficiency and compatibility domains.
+Since transitions in and out of the sandbox are relatively expensive, a guest
+operating system will typically take ownership of resources. For example, in the
+above case, the guest operating system may read the block device data in a local
+page cache, to avoid subsequent reads. This may lead to better performance but
+lower efficiency, since memory may be wasted or duplicated. The Sentry opts
+instead to defer to the host for many operations during runtime, for improved
+efficiency but lower performance in some use cases.
 
 ### What can a sandbox do?
 
@@ -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