[NaCl SDK Docs] Only generate one top-level <section> element.

native_client_sdk/doc_generated/reference/sandbox_internals/arm-32-bit-sandbox.html

 {{+bindTo:partials.standard_nacl_article}}
 
 <section id="arm-32-bit-sandbox">
 <span id="id1"></span><h1 id="arm-32-bit-sandbox"><span id="id1"></span>ARM 32-bit Sandbox</h1>
 <p>Native Client for ARM is a sandboxing technology for running
 programs&#8212;even malicious ones&#8212;safely, on computers that use 32-bit
 ARM processors. The ARM sandbox is an extension of earlier work on
 Native Client for x86 processors. Security is provided with a low
 performance overhead of about 10% over regular ARM code, and as you&#8217;ll
 see in this document the sandbox model is beautifully simple, meaning
@@ skipping 38 matching lines @@
 <ul class="small-gap">
 <li><a class="reference internal" href="#forbidden-instructions" id="id16">Forbidden Instructions</a></li>
 <li><a class="reference internal" href="#coprocessors" id="id17">Coprocessors</a></li>
 <li><a class="reference internal" href="#validator-code" id="id18">Validator Code</a></li>
 </ul>
 </li>
 </ul>
 </li>
 </ul>
 
-</div><section id="an-introduction-to-the-arm-architecture">
-<h2 id="an-introduction-to-the-arm-architecture">An Introduction to the ARM Architecture</h2>
+</div><h2 id="an-introduction-to-the-arm-architecture">An Introduction to the ARM Architecture</h2>
 <p>In this section, we summarize the relevant parts of the ARM processor
 architecture.</p>
-<section id="about-arm-and-armv7-a">
 <h3 id="about-arm-and-armv7-a">About ARM and ARMv7-A</h3>
 <p>ARM is one of the older commercial &#8220;RISC&#8221; processor designs, dating back
 to the early 1980s. Today, it is used primarily in embedded systems:
 everything from toys, to home automation, to automobiles. However, its
 most visible use is in cellular phones, tablets and some
 laptops.</p>
 <p>Through the years, there have been many revisions of the ARM
 architecture, written as ARMv<em>X</em> for some version <em>X</em>. Native Client
 specifically targets the ARMv7-A architecture commonly used in high-end
 phones and smartbooks. This revision, defined in the mid-2000s, adds a
 number of useful instructions, and specifies some portions of the system
 that used to be left to individual chip manufacturers. Critically,
 ARMv7-A specifies the &#8220;eXecute Never&#8221; bit, or <em>XN</em>. This pagetable
 attribute lets us mark memory as non-executable. Our security relies on
 the presence of this feature.</p>
 <p>ARMv8 adds a new 64-bit instruction set architecture called A64, while
 also enhancing the 32-bit A32 ISA. For Native Client&#8217;s purposes the A32
 ISA is equivalent to the ARMv7 ARM ISA, albeit with a few new
 instructions. This document only discussed the 32-bit A32 instruction
 set: A64 would require a different sandboxing model.</p>
-</section><section id="arm-programmer-s-model">
 <h3 id="arm-programmer-s-model">ARM Programmer&#8217;s Model</h3>
 <p>While modern ARM chips support several instruction encodings, 32-bit
 Native Client on ARM focuses on a single one: a fixed-width encoding
 where every instruction is 32-bits wide called A32 (previously, and
 confusingly, called simply ARM). Thumb, Thumb2 (now confusingly called
 T32), Jazelle, ThumbEE and such aren&#8217;t supported by Native Client. This
 dramatically simplifies some of our analyses, as we&#8217;ll see later. Nearly
 every instruction can be conditionally executed based on the contents of
 a dedicated condition code register.</p>
 <p>ARM processors have 16 general-purpose registers used for integer and
@@ skipping 27 matching lines @@
 <li>The <code>movw</code> and <code>movt</code> instructions can be used to set the top and
 bottom 16-bits of a register, and can therefore encode any 32-bit
 immediate.</li>
 <li>For values that can&#8217;t be represented as modified immediates, ARM
 programs use <code>pc</code>-relative loads to load data from inside the
 code&#8212;hidden in a place where it won&#8217;t be executed such as &#8220;constant
 pools&#8221;, just past the final return of a function.</li>
 </ol>
 <p>We&#8217;ll introduce more details of the ARM instruction set later, as we
 walk through the system.</p>
-</section></section><section id="the-native-client-approach">
 <h2 id="the-native-client-approach">The Native Client Approach</h2>
 <p>Native Client runs an untrusted program, potentially from an unknown or
 malicious source, inside a sandbox created by a trusted runtime. The
 trusted runtime allows the untrusted program to &#8220;call-out&#8221; and perform
 certain actions, such as drawing graphics, but prevents it from
 accessing the operating system directly. This &#8220;call-out&#8221; facility,
 called a trampoline, looks like a standard function call to the
 untrusted program, but it allows control to escape from the sandbox in a
 controlled way.</p>
 <p>The untrusted program and trusted runtime inhabit the same process, or
@@ skipping 25 matching lines @@
 compilers either. Instead, we apply a load-time validator that
 disassembles the program. The validator either proves that the program
 complies with our rules, or rejects it as unsafe. By keeping the rules
 simple, we keep the validator simple, small, and fast. We like to put
 our trust in small, simple things, and the validator is key to the
 system&#8217;s security.</p>
 <aside class="note">
 For the computationally-inclined, all our validators scale linearly in
 the size of the program.
 </aside>
-<section id="nacl-arm-pure-software-fault-isolation">
 <h3 id="nacl-arm-pure-software-fault-isolation">NaCl/ARM: Pure Software Fault Isolation</h3>
 <p>In the original Native Client system for the x86, we used unusual
 hardware features of that processor (the segment registers) to isolate
 untrusted programs. This was simple and fast, but won&#8217;t work on ARM,
 which has nothing equivalent. Instead, we use pure software fault
 isolation.</p>
 <p>We use a fixed address space layout: the untrusted program gets the
 lowest gigabyte, addresses <code>0</code> through <code>0x3FFFFFFF</code>. The rest of the
 address space holds the trusted runtime and the operating system. We
 isolate the program by requiring every <em>load</em>, <em>store</em>, and <em>indirect
 branch</em> (to an address in a register) to use a pseudo-instruction. The
 pseudo-instructions ensure that the address stays within the
 sandbox. The <em>indirect branch</em> pseudo-instruction, in turn, ensures that
 such branches won&#8217;t split up other pseudo-instructions.</p>
 <p>At either side of the sandbox, we place small (8KiB) guard
 regions. These are simply areas in the process&#8217;s address space that are
 mapped without read, write, or execute permissions, so any attempt to
 access them for any reason&#8212;<em>load</em>, <em>store</em>, or <em>jump</em>&#8212;will cause a
 fault.</p>
 <p>Finally, we ban the use of certain instructions, notably direct system
 calls. This is to ensure that the untrusted program can be run on any
 operating system supported by Native Client, and to prevent access to
 certain system features that might be used to subvert the sandbox. As a
 side effect, it helps to prevent programs from exploiting buggy
 operating system APIs.</p>
 <p>Let&#8217;s walk through the details, starting with the simplest part: <em>load</em>
 and <em>store</em>.</p>
-<section id="load-and-store">
 <h4 id="load-and-store"><em>Load</em> and <em>Store</em></h4>
 <p>All access to memory must be through <em>load</em> and <em>store</em>
 pseudo-instructions. These are simply a native <em>load</em> or <em>store</em>
 instruction, preceded by a guard instruction.</p>
 <p>Each <em>load</em> or <em>store</em> pseudo-instruction is similar to the <em>load</em> shown
 below. We use abstract &#8220;placeholder&#8221; registers instead of specific
 numbered registers for the sake of discussion. <code>rA</code> is the register
 holding the address to load from. <code>rD</code> is the destination for the
 loaded data.</p>
 <pre>
@@ skipping 11 matching lines @@
 <p>This illustrates a common property of all Native Client systems: we aim
 for safety, not correctness. A program using an invalid address in
 <code>rA</code> here is simply broken, so we are free to do whatever we want to
 preserve safety. In this case the program might load an invalid (but
 safe) value, or cause a segmentation fault limited to the untrusted
 code.</p>
 <p>Now, if we allowed arbitrary branches within the program, a malicious
 program could set up carefully-crafted values in <code>rA</code>, and then jump
 straight to the <code>ldr</code>. This is why we validate that programs never
 split pseudo-instructions.</p>
-<section id="alternative-sandboxing">
 <h5 id="alternative-sandboxing">Alternative Sandboxing</h5>
 <pre>
 tst    rA,  #0xC0000000
 ldreq  rD,  [rA]
 </pre>
 <p>The first instruction, <code>tst</code>, performs a bitwise-<code>AND</code> of <code>rA</code>
 and the modified immediate literal, <code>0xC0000000</code>. It sets the
 condition flags based on the result, but does not write the result to a
 register. In particular, it sets the <code>Z</code> condition flag if the result
 was zero&#8212;if the two values had no set bits in common. In this case,
@@ skipping 13 matching lines @@
 <aside class="note">
 The <code>tst</code>-based sequence is faster than the <code>bic</code>-based sequence
 on modern ARM chips. It avoids a data dependency in the address
 register. This is why we keep both around. The <code>tst</code>-based sequence
 unfortunately leaks information on some processors, and is therefore
 forbidden on certain processors. This effectively means that it cannot
 be used for regular Native Client <strong>nexe</strong> files, but can be used with
 Portable Native Client because the target processor is known at
 translation time from <strong>pexe</strong> to <strong>nexe</strong>.
 </aside>
-</section><section id="addressing-modes">
 <h5 id="addressing-modes">Addressing Modes</h5>
 <p>ARM has an unusually rich set of addressing modes. We allow all but one:
 register-indexed, where two registers are added to determine the
 address.</p>
 <p>We permit simple <em>load</em> and <em>store</em>, as shown above. We also permit
 displacement, pre-index, and post-index memory operations:</p>
 <pre>
 bic    rA,  #0xC0000000
 ldr    rD,  [rA, #1234]    ; This is fine.
 bic    rA,  #0xC0000000
 ldr    rD,  [rA, #1234]!   ; Also fine.
 bic    rA,  #0xC0000000
 ldr    rD,  [rA], #1234    ; Looking good.
 </pre>
 <p>In each case, we know <code>rA</code> points into the sandbox when the <code>ldr</code>
 executes. We allow adding an immediate displacement to <code>rA</code> to
 determine the final address (as in the first two examples here) because
 the largest immediate displacement is ±4095 bytes, while our guard pages
 are 8192 bytes wide.</p>
 <p>We also allow ARM&#8217;s more unusual <em>load</em> and <em>store</em> instructions, such
 as <em>load-multiple</em> and <em>store-multiple</em>, etc.</p>
-</section><section id="conditional-load-and-store">
 <h5 id="conditional-load-and-store">Conditional <em>Load</em> and <em>Store</em></h5>
 <p>There&#8217;s one problem with the pseudo-instructions shown above: they are
 unconditional (assuming <code>rA</code> is valid). ARM compilers regularly use
 conditional <em>load</em> and <em>store</em>, so we should support this in Native
 Client. We do so by defining alternate, predictable
 pseudo-instructions. Here is a conditional <em>store</em>
 (<em>store-if-greater-than</em>) using this pseudo-instruction sequence:</p>
 <pre>
 bicgt  rA,  #0xC0000000
 strgt  rX,  [rA, #123]
 </pre>
-</section></section><section id="the-stack-pointer-thread-pointer-and-program-counter">
 <h4 id="the-stack-pointer-thread-pointer-and-program-counter">The Stack Pointer, Thread Pointer, and Program Counter</h4>
-<section id="stack-pointer">
 <h5 id="stack-pointer">Stack Pointer</h5>
 <p>In C-like languages, the stack is used to store return addresses during
 function calls, as well as any local variables that won&#8217;t fit in
 registers. This makes stack operations very common.</p>
 <p>Native Client does not require guard instructions on any <em>load</em> or
 <em>store</em> involving the stack pointer, <code>sp</code>. This improves performance
 and reduces code size. However, ARM&#8217;s stack pointer isn&#8217;t special: it&#8217;s
 just another register, called <code>sp</code> only by convention. To make it safe
 to use this register as a <em>load</em> or <em>store</em> address without guards, we
 add a rule: <code>sp</code> must always contain a valid address.</p>
@@ skipping 18 matching lines @@
 <p>The <code>bic</code> is similar to the one we used for conditional <em>load</em> and
 <em>store</em>, and serves exactly the same purpose: after it completes, <code>sp</code>
 is a valid address.</p>
 <aside class="note">
 Clever assembly programmers and compilers may want to use this
 &#8220;trusted&#8221; property of <code>sp</code> to emit more efficient code: in a hot
 loop instead of using <code>sp</code> as a stack pointer it can be temporarily
 used as an index pointer (e.g. to traverse an array). This avoids the
 extra <code>bic</code> whenever the pointer is updated in the loop.
 </aside>
-</section><section id="thread-pointer-loads">
 <h5 id="thread-pointer-loads">Thread Pointer Loads</h5>
 <p>The thread pointer and IRT thread pointer are stored in the trusted
 address space. All uses and definitions of <code>r9</code> from untrusted code
 are forbidden except as follows:</p>
 <pre>
 ldr Rn, [r9]     ; Load user thread pointer.
 ldr Rn, [r9, #4] ; Load IRT thread pointer.
 </pre>
-</section><section id="pc-relative-loads">
 <h5 id="pc-relative-loads"><code>pc</code>-relative Loads</h5>
 <p>By extension, we also allow <em>load</em> through the <code>pc</code> without a
 mask. The explanation is quite similar:</p>
 <ul class="small-gap">
 <li>Our control-flow isolation rules mean that the <code>pc</code> will always
 point into the sandbox.</li>
 <li>The maximum immediate displacement that can be used in a
 <code>pc</code>-relative <em>load</em> is smaller than the width of the guard pages.</li>
 </ul>
 <p>We do not allow <code>pc</code>-relative stores, because they look suspiciously
 like self-modifying code, or any addressing mode that would alter the
 <code>pc</code> as a side effect of the <em>load</em>.</p>
-</section></section><section id="indirect-branch">
 <h4 id="indirect-branch"><em>Indirect Branch</em></h4>
 <p>There are two types of control flow on ARM: direct and indirect. Direct
 control flow instructions have an embedded target address or
 offset. Indirect control flow instructions take their destination
 address from a register. The <code>b</code> (branch) and <code>bl</code>
 (<em>branch-with-link</em>) instructions are <em>direct branch</em> and <em>call</em>,
 respectively. The <code>bx</code> (<em>branch-exchange</em>) and <code>blx</code>
 (<em>branch-with-link-exchange</em>) are the indirect equivalents.</p>
 <p>Because the program counter <code>pc</code> is simply another register, ARM also
 has many implicit indirect control flow instructions. Programs can
 operate on the <code>pc</code> using <em>add</em> or <em>load</em>, or even outlandish (and
 often specified as having unpredictable-behavior) things like multiply!
 In Native Client we ban all such instructions. Indirect control flow is
 exclusively through <code>bx</code> and <code>blx</code>. Because all of ARM&#8217;s control
 flow instructions are called <em>branch</em> instructions, we&#8217;ll use the term
 <em>indirect branch</em> from here on, even though this includes things like
 <em>virtual call</em>, <em>return</em>, and the like.</p>
-<section id="the-trouble-with-indirection">
 <h5 id="the-trouble-with-indirection">The Trouble with Indirection</h5>
 <p><em>Indirect branch</em> present two problems for Native Client:</p>
 <ul class="small-gap">
 <li>We must ensure that they don&#8217;t send execution outside the sandbox.</li>
 <li>We must ensure that they don&#8217;t break up the instructions inside a
 pseudo-instruction, by landing on the second one.</li>
 </ul>
 <aside class="note">
 On the x86 architectures we must also ensure that it doesn&#8217;t land
 inside an instruction. This is unnecessary on ARM, where all
 instructions are 32-bit wide.
 </aside>
 <p>Checking both of these for <em>direct branch</em> is easy: the validator just
 pulls the (fixed) target address out of the instruction and checks what
 it points to.</p>
-</section><section id="the-native-client-solution-bundles">
 <h5 id="the-native-client-solution-bundles">The Native Client Solution: &#8220;Bundles&#8221;</h5>
 <p>For <em>indirect branch</em>, we can address the first problem by simply
 masking some high-order bits off the address, like we did for <em>load</em> and
 <em>store</em>. The second problem is more subtle. Detecting every possible
 route that every <em>indirect branch</em> might take is difficult. Instead, we
 take the approach pioneered by the original Native Client: we restrict
 the possible places that any <em>indirect branch</em> can land. On Native
 Client for ARM, <em>indirect branch</em> can target any address that has its
 bottom four bits clear&#8212;any address that&#8217;s <code>0 mod 16</code>. We call these
 16-byte chunks of code &#8220;bundles&#8221;. The validator makes sure that no
@@ skipping 51 matching lines @@
 A32 code that&#8217;s actually very naughty T32 code, somewhat like forming
 a sentence that happens to be valid in English and French but with
 completely different meanings, complimenting the reader in one
 language and insulting them in the other.</p>
 <p>You&#8217;ve figured out by now that the bundle alignment restrictions of
 the Native Client sandbox already take care of making this travesty
 impossible: by masking off the bottom 4 bits of the destination the
 interworking nature of ARM&#8217;s <em>indirect branch</em> is completely avoided.</p>
 
 </aside>
-</section><section id="call-and-return">
 <h5 id="call-and-return"><em>Call</em> and <em>Return</em></h5>
 <p>On ARM, there is no <em>call</em> or <em>return</em> instruction. A <em>call</em> is simply a
 <em>branch</em> that just happen to load a return address into <code>lr</code>, the link
 register. If the called function is a leaf (that is, if it calls no
 other functions before returning), it simply branches to the address
 stored in <code>lr</code> to <em>return</em> to its caller:</p>
 <pre>
 bic  lr,  #0xC000000F
 bx   lr
 </pre>
@@ skipping 24 matching lines @@
 Client doesn&#8217;t try to prevent infinite loops, but the validator actually
 does check the alignment of calls. This is because, when we were writing
 the compiler, it was annoying to find out our calls were in the wrong
 place by having the program run forever!)</p>
 <aside class="note">
 Properly balancing the CPU&#8217;s <em>call</em>/<em>return</em> actually allows it to
 perform much better by allowing it to speculatively execute the return
 address&#8217; code. For more information on ARM&#8217;s <em>call</em>/<em>return</em> stack see
 ARM&#8217;s technical reference manual.
 </aside>
-</section></section><section id="literal-pools-and-data-bundles">
 <h4 id="literal-pools-and-data-bundles">Literal Pools and Data Bundles</h4>
 <p>In the section where we described the ARM architecture, we mentioned
 ARM&#8217;s unusual immediate forms. To restate:</p>
 <ul class="small-gap">
 <li>ARM instructions are fixed-length, 32-bits, so we can&#8217;t have an
 instruction that includes an arbitrary 32-bit constant.</li>
 <li>Many ARM instructions can include a modified immediate constant, which
 is flexible, but limited.</li>
 <li>For any other value (particularly addresses), ARM programs explicitly
 load constants from inside the code itself.</li>
@@ skipping 30 matching lines @@
 in Native Client... but there&#8217;s a potential flaw. If we let programs
 contain arbitrary data, mingled in with the code, couldn&#8217;t they hide
 malicious instructions this way?</p>
 <p>The answer is no, because the validator disassembles the entire
 executable region of the program, without regard to whether the
 programmer said a certain chunk was code or data. But this brings the
 opposite problem: what if the program needs to contain a certain
 constant that just happens to encode a malicious instruction?  We want
 to allow this, but we have to be certain it will never be executed as
 code!</p>
-<section id="data-bundles-to-the-rescue">
 <h5 id="data-bundles-to-the-rescue">Data Bundles to the Rescue</h5>
 <p>As we discussed in the last section, ARM code in Native Client is
 structured in 16-byte bundles. We allow literal pools by putting them in
 special bundles, called data bundles. Each data bundle can contain 12
 bytes of arbitrary data, and the program can have as many data bundles
 as it likes.</p>
 <p>Each data bundle starts with a breakpoint instruction, <code>bkpt</code>. This
 way, if an <em>indirect branch</em> tries to enter the data bundle, the process
 will take a fault and the trusted runtime will intervene (by terminating
 the program). For example:</p>
@@ skipping 19 matching lines @@
 awfully specific when you just need a special &#8220;roadblock&#8221; instruction!
 Quite true, young Padawan! It happens that this odd <code>bkpt</code>
 instruction is encoded as <code>0xE125BE70</code> in A32, and in T32 the
 <code>bkpt</code> instruction is encoded as <code>0xBExx</code> (where <code>xx</code> could be
 any 8-bit immediate, say <code>0x70</code>) and <code>0xE125</code> encodes the <em>branch</em>
 instruction <code>b.n #0x250</code>. The special roadblock instruction
 therefore doubles as a roadblock in T32, if anything were to go so
 awry that we tried to execute it as a T32 instruction! Much defense,
 such depth, wow!
 </aside>
-</section></section></section><section id="trampolines-and-memory-layout">
 <h3 id="trampolines-and-memory-layout">Trampolines and Memory Layout</h3>
 <p>So far, the rules we&#8217;ve described make for boring programs: they can&#8217;t
 communicate with the outside world!</p>
 <ul class="small-gap">
 <li>The program can&#8217;t call an external library, or the operating system,
 even to do something simple like draw some pixels on the screen.</li>
 <li>It also can&#8217;t read or write memory outside of its dedicated sandbox,
 so communicating that way is right out.</li>
 </ul>
 <p>We fix this by allowing the untrusted program to call into the trusted
 runtime using a trampoline. A trampoline is simply a short stretch of
 code, placed by the trusted runtime at a known location within the
 sandbox, that is permitted to do things the untrusted program can&#8217;t.</p>
 <p>Even though trampolines are inside the sandbox, the untrusted program
 can&#8217;t modify them: the trusted runtime marks them read-only. It also
 can&#8217;t do anything clever with the special instructions inside the
 trampoline&#8212;for example, call it at a slightly offset address to bypass
 some checks&#8212;because the validator only allows trampolines to be
 reached by <em>indirect branch</em> (or <em>branch-with-link</em>). We structure the
 trampolines carefully so that they&#8217;re safe to enter at any <code>0 mod 16</code>
 address.</p>
 <p>The validator can detect attempts to use the trampolines because they&#8217;re
 loaded at a fixed location in memory. Let&#8217;s look at the memory map of
 the Native Client sandbox.</p>
-<section id="memory-map">
 <h4 id="memory-map">Memory Map</h4>
 <p>The ARM sandbox is always at virtual address <code>0</code>, and is exactly 1GiB
 in size. This includes the untrusted program&#8217;s code and data, the
 trampolines, and a small guard region to detect null pointer
 dereferences. In practice, the untrusted program takes up a bit more
 room than this, because of the need for additional guard regions at
 either end of the sandbox.</p>
 <table border="1" class="docutils">
 <colgroup>
 </colgroup>
@@ skipping 36 matching lines @@
 that&#8217;s <code>0 mod 16</code>. However, only even slots are used, so useful
 trampolines are always <code>0 mod 32</code>. If the program calls an odd slot,
 it will fault, and the trusted runtime will shut it down.</p>
 <aside class="note">
 This is a bit of speculative flexibility. While the current bundle
 size of Native Client on ARM is 16 bytes, we&#8217;ve considered the
 possibility of optional 32-byte bundles, to enable certain compiler
 improvements. While this option isn&#8217;t available to untrusted programs
 today, we&#8217;re trying to keep the system &#8220;32-byte clean&#8221;.
 </aside>
-</section><section id="inside-a-trampoline">
 <h4 id="inside-a-trampoline">Inside a Trampoline</h4>
 <p>When we introduced trampolines, we mentioned that they can do things
 that untrusted programs can&#8217;t. To be more specific, trampolines can jump
 to locations outside the sandbox. On ARM, this is all they do. Here&#8217;s a
 typical trampoline fragment on ARM:</p>
 <pre>
 ; Even trampoline bundle:
 push  { r0-r3 }     ; Save arguments that may be in registers.
 push  { lr }        ; Save the untrusted return address,
                     ; separate step because it must be on top.
 ldr   r0,  [pc, #4] ; Load the destination address from
                     ; the next bundle.
 blx   r0            ; Go!
 ; The odd trampoline that immediately follows:
 bkpt 0x5be0         ; Prevent entry to this data bundle.
 .word address_of_routine
 </pre>
 <p>The only odd thing here is that we push the incoming value of <code>lr</code>,
 and then use <code>blx</code>&#8212;not <code>bx</code>&#8212;to escape the sandbox. This is
 because, in practice, all trampolines jump to the same routine in the
 trusted runtime, called the syscall hook. It uses the return address
 produced by the final <code>blx</code> instruction to determine which trampoline
 was called.</p>
-</section></section><section id="loose-ends">
 <h3 id="loose-ends">Loose Ends</h3>
-<section id="forbidden-instructions">
 <h4 id="forbidden-instructions">Forbidden Instructions</h4>
 <p>To complete the sandbox, the validator ensures that the program does not
 try to use certain forbidden instructions.</p>
 <ul class="small-gap">
 <li>We forbid instructions that directly interact with the operating
 system by going around the trusted runtime. We prevent this to limit
 the functionality of the untrusted program, and to ensure portability
 across operating systems.</li>
 <li>We forbid instructions that change the processor&#8217;s execution mode to
 Thumb, ThumbEE, or Jazelle. This would cause the code to be
@@ skipping 35 matching lines @@
 <li><code>STM</code>, kernel version: not available to user code.</li>
 <li><code>STR*T</code> (unprivileged store operations): theoretically harmless,
 but suspicious when found in user code. Use <code>STR</code> instead.</li>
 <li><code>SVC</code>/<code>SWI</code>: allows direct operating system interaction.</li>
 <li>Any unassigned hint instruction: difficult to reason about, so
 treated as suspicious.</li>
 </ul>
 <p>More details are available in the <a class="reference external" href="http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/armv7.table">ARMv7 instruction table definition</a>.</p>
 
 </aside>
-</section><section id="coprocessors">
 <h4 id="coprocessors">Coprocessors</h4>
 <p>ARM has traditionally added new instruction set features through
 coprocessors. Coprocessors are accessed through a small set of
 instructions, and often have their own register files. Floating point
 and the NEON vector extensions are both implemented as coprocessors, as
 is the MMU.</p>
 <p>We&#8217;re confident that the side-effects of coprocessors in slots 10 and 11
 (that is, floating point, NEON, etc.) are well-understood. These are in
 the coprocessor space reserved by ARM Ltd. for their own extensions
 (<code>CP8</code>&#8211;<code>CP15</code>), and are unlikely to change significantly. So, we
 allow untrusted code to use coprocessors 10 and 11, and we mandate the
 presence of at least VFPv3 and NEON/AdvancedSIMD. Multiprocessor
 Extension, VFPv4, FP16 and other extensions are allowed but not
 required, and may fail on processors that do not support them, it is
 therefore the program&#8217;s responsibility to validate their availability
 before executing them.</p>
 <p>We don&#8217;t allow access to any other ARM-reserved coprocessor
 (<code>CP8</code>&#8211;<code>CP9</code> or <code>CP12</code>&#8211;<code>CP15</code>). It&#8217;s possible that read
 access to <code>CP15</code> might be useful, and we might allow it in the
 future&#8212;but again, it&#8217;s easier to loosen the restrictions than tighten
 them, so we ban it for now.</p>
 <p>We do not, and probably never will, allow access to the vendor-specific
 coprocessor space, <code>CP0</code>&#8211;<code>CP7</code>. We&#8217;re simply not confident in our
 ability to model the operations on these coprocessors, given that
 vendors often leave them poorly-specified. Unfortunately this eliminates
 some legacy floating point and vector implementations, but these are
 superceded on ARMv7-A parts anyway.</p>
-</section><section id="validator-code">
 <h4 id="validator-code">Validator Code</h4>
 <p>By now you&#8217;re itching to see the sandbox validator&#8217;s code and dissect
 it. You&#8217;ll have a disapointing read: at less that 500 lines of code
 <a class="reference external" href="http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/validator.cc">validator.cc</a>
 is quite simple to understand and much shorter than this document. It&#8217;s
 of course dependent on the <a class="reference external" href="http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/armv7.table">ARMv7 instruction table definition</a>,
 which teaches it about the ARMv7 instruction set.</p>
-</section></section></section></section>
+</section>
 
 {{/partials.standard_nacl_article}}