Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(46)

Side by Side Diff: native_client_sdk/doc_generated/reference/sandbox_internals/arm-32-bit-sandbox.html

Issue 173343004: NaCl documentation: nits on ARM sandbox documentation (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: Created 6 years, 10 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch | Annotate | Revision Log
« no previous file with comments | « no previous file | native_client_sdk/src/doc/reference/sandbox_internals/arm-32-bit-sandbox.rst » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
1 {{+bindTo:partials.standard_nacl_article}} 1 {{+bindTo:partials.standard_nacl_article}}
2 2
3 <section id="arm-32-bit-sandbox"> 3 <section id="arm-32-bit-sandbox">
4 <h1 id="arm-32-bit-sandbox">ARM 32-bit Sandbox</h1> 4 <h1 id="arm-32-bit-sandbox">ARM 32-bit Sandbox</h1>
5 <p>Native Client for ARM is a sandboxing technology for running 5 <p>Native Client for ARM is a sandboxing technology for running
6 programs&#8212;even malicious ones&#8212;safely, on computers that use 32-bit 6 programs&#8212;even malicious ones&#8212;safely, on computers that use 32-bit
7 ARM processors. The ARM sandbox is an extension of earlier work on 7 ARM processors. The ARM sandbox is an extension of earlier work on
8 Native Client for x86 processors. Security is provided with a low 8 Native Client for x86 processors. Security is provided with a low
9 performance overhead of about 10% over regular ARM code, and as you&#8217;ll 9 performance overhead of about 10% over regular ARM code, and as you&#8217;ll
10 see in this document the sandbox model is beautifully simple, meaning 10 see in this document the sandbox model is beautifully simple, meaning
(...skipping 393 matching lines...) Expand 10 before | Expand all | Expand 10 after
404 <h5 id="the-native-client-solution-bundles">The Native Client Solution: &#8220;B undles&#8221;</h5> 404 <h5 id="the-native-client-solution-bundles">The Native Client Solution: &#8220;B undles&#8221;</h5>
405 <p>For <em>indirect branch</em>, we can address the first problem by simply 405 <p>For <em>indirect branch</em>, we can address the first problem by simply
406 masking some high-order bits off the address, like we did for <em>load</em> and 406 masking some high-order bits off the address, like we did for <em>load</em> and
407 <em>store</em>. The second problem is more subtle. Detecting every possible 407 <em>store</em>. The second problem is more subtle. Detecting every possible
408 route that every <em>indirect branch</em> might take is difficult. Instead, we 408 route that every <em>indirect branch</em> might take is difficult. Instead, we
409 take the approach pioneered by the original Native Client: we restrict 409 take the approach pioneered by the original Native Client: we restrict
410 the possible places that any <em>indirect branch</em> can land. On Native 410 the possible places that any <em>indirect branch</em> can land. On Native
411 Client for ARM, <em>indirect branch</em> can target any address that has its 411 Client for ARM, <em>indirect branch</em> can target any address that has its
412 bottom four bits clear&#8212;any address that&#8217;s <code>0 mod 16</code>. We call these 412 bottom four bits clear&#8212;any address that&#8217;s <code>0 mod 16</code>. We call these
413 16-byte chunks of code &#8220;bundles&#8221;. The validator makes sure that no 413 16-byte chunks of code &#8220;bundles&#8221;. The validator makes sure that no
414 pseudo-instruction straddles a bundle boundary. Compilers must pad with` 414 pseudo-instruction straddles a bundle boundary. Compilers must pad with
415 <cite>nop`</cite>s to ensure that every pseudo-instruction fits entirely inside 415 <code>nop</code> to ensure that every pseudo-instruction fits entirely inside on e
416 one bundle.</p> 416 bundle.</p>
417 <p>Here is the <em>indirect branch</em> pseudo-instruction. As you can see, it 417 <p>Here is the <em>indirect branch</em> pseudo-instruction. As you can see, it
418 clears the top two and bottom four bits of the address:</p> 418 clears the top two and bottom four bits of the address:</p>
419 <pre> 419 <pre>
420 bic rA, #0xC000000F 420 bic rA, #0xC000000F
421 bx rA 421 bx rA
422 </pre> 422 </pre>
423 <p>This particular pseudo-instruction (a <code>bic</code> followed by a <code>bx </code>) is 423 <p>This particular pseudo-instruction (a <code>bic</code> followed by a <code>bx </code>) is
424 used for computed jumps in switch tables and returning from functions, 424 used for computed jumps in switch tables and returning from functions,
425 among other uses. Recall that, under ARM&#8217;s modified immediate rules, we 425 among other uses. Recall that, under ARM&#8217;s modified immediate rules, we
426 can fit the constant <code>0xC000000F</code> into the <code>bic</code> instructi on&#8217;s 426 can fit the constant <code>0xC000000F</code> into the <code>bic</code> instructi on&#8217;s
(...skipping 146 matching lines...) Expand 10 before | Expand all | Expand 10 after
573 <p>As we discussed in the last section, ARM code in Native Client is 573 <p>As we discussed in the last section, ARM code in Native Client is
574 structured in 16-byte bundles. We allow literal pools by putting them in 574 structured in 16-byte bundles. We allow literal pools by putting them in
575 special bundles, called data bundles. Each data bundle can contain 12 575 special bundles, called data bundles. Each data bundle can contain 12
576 bytes of arbitrary data, and the program can have as many data bundles 576 bytes of arbitrary data, and the program can have as many data bundles
577 as it likes.</p> 577 as it likes.</p>
578 <p>Each data bundle starts with a breakpoint instruction, <code>bkpt</code>. Thi s 578 <p>Each data bundle starts with a breakpoint instruction, <code>bkpt</code>. Thi s
579 way, if an <em>indirect branch</em> tries to enter the data bundle, the process 579 way, if an <em>indirect branch</em> tries to enter the data bundle, the process
580 will take a fault and the trusted runtime will intervene (by terminating 580 will take a fault and the trusted runtime will intervene (by terminating
581 the program). For example:</p> 581 the program). For example:</p>
582 <pre> 582 <pre>
583 .p2align 4
583 bkpt #0x5BE0 ; Must be aligned 0 mod 16! 584 bkpt #0x5BE0 ; Must be aligned 0 mod 16!
584 .word 0xDEADBEEF ; Arbitrary constants are A-OK. 585 .word 0xDEADBEEF ; Arbitrary constants are A-OK.
585 svc #30 ; Trying to make a syscall? OK! 586 svc #30 ; Trying to make a syscall? OK!
586 str r0, [r1] ; Unmasked stores are fine too. 587 str r0, [r1] ; Unmasked stores are fine too.
587 </pre> 588 </pre>
588 <p>So, we have a way for programs to create an arbitrary, even dangerous, 589 <p>So, we have a way for programs to create an arbitrary, even dangerous,
589 chunk of data within their code. We can prevent <em>indirect branch</em> from 590 chunk of data within their code. We can prevent <em>indirect branch</em> from
590 entering it. We can also prevent fall-through from the code just before 591 entering it. We can also prevent fall-through from the code just before
591 it, by the <code>bkpt</code>. But what about <em>direct branch</em> straight int o the 592 it, by the <code>bkpt</code>. But what about <em>direct branch</em> straight int o the
592 middle?</p> 593 middle?</p>
(...skipping 210 matching lines...) Expand 10 before | Expand all | Expand 10 after
803 <h4 id="validator-code">Validator Code</h4> 804 <h4 id="validator-code">Validator Code</h4>
804 <p>By now you&#8217;re itching to see the sandbox validator&#8217;s code and dis sect 805 <p>By now you&#8217;re itching to see the sandbox validator&#8217;s code and dis sect
805 it. You&#8217;ll have a disapointing read: at less that 500 lines of code 806 it. You&#8217;ll have a disapointing read: at less that 500 lines of code
806 <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 > 807 <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 >
807 is quite simple to understand and much shorter than this document. It&#8217;s 808 is quite simple to understand and much shorter than this document. It&#8217;s
808 of course dependent on the <a class="reference external" href="http://src.chromi um.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/ar mv7.table">ARMv7 instruction table definition</a>, 809 of course dependent on the <a class="reference external" href="http://src.chromi um.org/viewvc/native_client/trunk/src/native_client/src/trusted/validator_arm/ar mv7.table">ARMv7 instruction table definition</a>,
809 which teaches it about the ARMv7 instruction set.</p> 810 which teaches it about the ARMv7 instruction set.</p>
810 </section></section></section></section> 811 </section></section></section></section>
811 812
812 {{/partials.standard_nacl_article}} 813 {{/partials.standard_nacl_article}}
OLDNEW
« no previous file with comments | « no previous file | native_client_sdk/src/doc/reference/sandbox_internals/arm-32-bit-sandbox.rst » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698