NaCl documentation: nits on ARM sandbox documentation

native_client_sdk/src/doc/reference/sandbox_internals/arm-32-bit-sandbox.rst

 ==================
 ARM 32-bit Sandbox
 ==================
 
 Native Client for ARM is a sandboxing technology for running
 programs---even malicious ones---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'll
 see in this document the sandbox model is beautifully simple, meaning
@@ skipping 444 matching lines @@
 
 For *indirect branch*, we can address the first problem by simply
 masking some high-order bits off the address, like we did for *load* and
 *store*. The second problem is more subtle. Detecting every possible
 route that every *indirect branch* might take is difficult. Instead, we
 take the approach pioneered by the original Native Client: we restrict
 the possible places that any *indirect branch* can land. On Native
 Client for ARM, *indirect branch* can target any address that has its
 bottom four bits clear---any address that's ``0 mod 16``. We call these
 16-byte chunks of code "bundles". The validator makes sure that no
-pseudo-instruction straddles a bundle boundary. Compilers must pad with`
-`nop``\ s to ensure that every pseudo-instruction fits entirely inside
-one bundle.
+pseudo-instruction straddles a bundle boundary. Compilers must pad with
+``nop`` to ensure that every pseudo-instruction fits entirely inside one
+bundle.
 
 Here is the *indirect branch* pseudo-instruction. As you can see, it
 clears the top two and bottom four bits of the address:
 
 .. naclcode::
   :prettyprint: 0
 
   bic  rA,  #0xC000000F
   bx   rA
 
@@ skipping 182 matching lines @@
 as it likes.
 
 Each data bundle starts with a breakpoint instruction, ``bkpt``. This
 way, if an *indirect branch* tries to enter the data bundle, the process
 will take a fault and the trusted runtime will intervene (by terminating
 the program). For example:
 
 .. naclcode::
   :prettyprint: 0
 
+  .p2align 4
   bkpt #0x5BE0          ; Must be aligned 0 mod 16!
   .word 0xDEADBEEF      ; Arbitrary constants are A-OK.
   svc #30               ; Trying to make a syscall? OK!
   str r0, [r1]          ; Unmasked stores are fine too.
 
 So, we have a way for programs to create an arbitrary, even dangerous,
 chunk of data within their code. We can prevent *indirect branch* from
 entering it. We can also prevent fall-through from the code just before
 it, by the ``bkpt``. But what about *direct branch* straight into the
 middle?
@@ skipping 214 matching lines @@
 ^^^^^^^^^^^^^^
 
 By now you're itching to see the sandbox validator's code and dissect
 it. You'll have a disapointing read: at less that 500 lines of code
 `validator.cc
 <http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/validator.cc>`_
 is quite simple to understand and much shorter than this document. It's
 of course dependent on the `ARMv7 instruction table definition
 <http://src.chromium.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/armv7.table>`_,
 which teaches it about the ARMv7 instruction set.