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

native_client_sdk/doc_generated/reference/sandbox_internals/x86-64-sandbox.html

 {{+bindTo:partials.standard_nacl_article}}
 
 <section id="nacl-sfi-model-on-x86-64-systems">
 <span id="x86-64-sandbox"></span><h1 id="nacl-sfi-model-on-x86-64-systems"><span id="x86-64-sandbox"></span>NaCl SFI model on x86-64 systems</h1>
 <div class="contents local" id="contents" style="display: none">
 <ul class="small-gap">
 <li><a class="reference internal" href="#summary" id="id5">Summary</a></li>
 <li><a class="reference internal" href="#binary-format" id="id6">Binary Format</a></li>
 <li><a class="reference internal" href="#runtime-invariants" id="id7">Runtime Invariants</a></li>
 <li><a class="reference internal" href="#text-segment-rules" id="id8">Text Segment Rules</a></li>
 <li><a class="reference internal" href="#list-of-pseudo-instructions" id="id9">List of Pseudo-instructions</a></li>
 </ul>
 
-</div><section id="summary">
-<h2 id="summary">Summary</h2>
+</div><h2 id="summary">Summary</h2>
 <p>This document addresses the details of the Software Fault Isolation
 (SFI) model for executable code that can be run in Native Client on an
 x86-64 system. An overview of this model can be found in the paper:
 <a class="reference external" href="https://research.google.com/pubs/archive/35649.pdf">Adapting Software Fault Isolation to Contemporary CPU Architectures</a>.
 The primary focus of the SFI model is a Windows x86-64 system but the
 same techniques can be applied to run identical x86-64 binaries on
 other x86-64 systems such as Linux, Mac, FreeBSD, etc, so the
 description of the SFI model tries to abstract away system
 dependencies when possible.</p>
 <p>Please note: throughout this document we use the AT&amp;T notation for
 assembler syntax, in which the target operand appears last, e.g. <code>mov
 src, dst</code>.</p>
-</section><section id="binary-format">
 <h2 id="binary-format">Binary Format</h2>
 <p>The format of Native Client executable binaries is identical to the
 x86-64 ELF binary format (<a class="reference external" href="http://en.wikipedia.org/wiki/Executable_and_Linkable_Format">[0]</a>, <a class="reference external" href="http://www.sco.com/developers/devspecs/gabi41.pdf">[1]</a>, <a class="reference external" href="http://www.sco.com/developers/gabi/latest/contents.html">[2]</a>, <a class="reference external" href="http://downloads.openwatcom.org/ftp/devel/docs/elf-64-gen.pdf">[3]</a>) for
 Linux or BSD with a few extra requirements. The additional rules that
 a Native Client ELF binary must follow are:</p>
 <ul class="small-gap">
 <li>The ELF magic OS ABI field must be 123.</li>
 <li>The ELF magic OS ABI VERSION field must be 5.</li>
 <li>The ELF e_flags field must be 0x200000 (32-byte alignment).</li>
 <li>There must be exactly one PT_LOAD text segment. It must begin at
 0x20000 (128 kB) and be marked RX (no W). The contents of the text
 segment must follow <a class="reference internal" href="#x86-64-text-segment-rules"><em>Text Segment Rules</em></a>.</li>
 <li>There can be at most one PT_LOAD data segment marked R.</li>
 <li>There can be at most one PT_LOAD data segment marked RW.</li>
 <li>There can be at most one PT_GNU_STACK segment. It must be marked RW.</li>
 <li>All segments must end before limit address (4 GiB).</li>
 </ul>
-</section><section id="runtime-invariants">
 <h2 id="runtime-invariants">Runtime Invariants</h2>
 <p>To ensure fault isolation at runtime, the system must maintain a
 number of runtime <em>invariants</em> across the lifetime of the running
 program. Both the <em>Validator</em> and the <em>Service Runtime</em> are
 responsible for maintaining the invariants. See the paper for the
 rationale for the invariants:</p>
 <ul class="small-gap">
 <li><code>RIP</code> always points to valid instruction boundary (the validator must
 ensure this with direct jumps and direct calls).</li>
 <li><code>R15</code> (aka <code>RBASE</code> and <code>RZP</code>) is never modified by code (the
@@ skipping 22 matching lines @@
 guaranteed to obey the invariant.</li>
 </ul>
 </div></blockquote>
 <ul class="small-gap">
 <li>Trampoline/springboard code is mapped to a non-writable region in
 the <em>untrusted 84GB region</em>; each trampoline/springboard is 32-byte
 aligned and fits within a single <em>bundle</em>.</li>
 <li>The OS must not put any internal structures/code into the untrusted
 region at any time (not using OS dynamic linker, etc)</li>
 </ul>
-</section><section id="text-segment-rules">
-<span id="x86-64-text-segment-rules"></span><h2 id="text-segment-rules"><span id="x86-64-text-segment-rules"></span>Text Segment Rules</h2>
+<h2 id="text-segment-rules"><span id="x86-64-text-segment-rules"></span>Text Segment Rules</h2>
 <ul class="small-gap">
 <li>The validation process must ensure that the text segment complies
 with the following rules. The validation process must complete
 successfully strictly before executing any instruction of the
 untrusted code.</li>
 <li>The following instructions are illegal and must be rejected by the
 validator (the list is not exhaustive as the validator uses a
 whiteist, not a blacklist; this means there is a large but finite
 list of instructions the validator allows, not a small list of
 instructions the validator rejects):</li>
@@ skipping 86 matching lines @@
  add %rZP, %rsp  ; restoration of %RSP from %RBP with adjust
  sub ..., %esp
  add %rZP, %rsp  ; stack space allocation
  add ..., %esp
  add %rZP, %rsp  ; stack space deallocation
  and $XX, %rsp  ; alignment; XX must be between -128 and -1
  pushq ...
  popq ...  ; except pop %RSP, pop %RBP
 </pre>
 </div></blockquote>
-</section><section id="list-of-pseudo-instructions">
 <h2 id="list-of-pseudo-instructions">List of Pseudo-instructions</h2>
 <p>Pseudo-instructions were introduced to let the compiler maintain the
 invariants without needing to know the code alignment rules. The
 assembler guarantees 32-bit alignment for all <em>pseudo-instructions</em> in
 the table below. In addition, to the pseudo-instructions, one
 pseudo-operand prefix is introduced: <code>%nacl</code>. Presence of the
 <code>%nacl</code> operand prefix ensures that:</p>
 <ul class="small-gap">
 <li>The instruction <code>&quot;%mov %eXX, %eXX&quot;</code> is added immediately before the
 actual command using prefix <code>%nacl</code> (where <code>%eXX</code> is a 32-bit
@@ skipping 107 matching lines @@
 </tr>
 <tr>
 <td>[rep] stos %?ax,%nacl:(%rdi),%rZP<br/>
 <i>(sandboxed stos)</i></td>
 <td>mov %edi,%edi<br/>
 lea (%rZP,%rdi,1),%rdi<br/>
 [rep] stos %?ax,(%rdi)<br/>
 </td>
 </tr>
 </tbody>
-</table></section></section>
+</table></section>
 
 {{/partials.standard_nacl_article}}