Avoid writing the sandbox base address to memory in setjmp and memcpy

newlib/libc/machine/x86_64/memcpy.S

 /*
  * ====================================================
  * Copyright (C) 2007 by Ellips BV. All rights reserved.
  *
  * Permission to use, copy, modify, and distribute this
  * software is freely granted, provided that this notice
  * is preserved.
  * ====================================================
  */
 
@@ skipping 22 matching lines @@
   jb      quadword_copy
 
   pushq    rax
   pushq    r12
   pushq    r13
   pushq    r14
 
   movl    edx, ecx                /* Copy 128 bytes at a time with minimum cache polution */
   shrl    $7, ecx
 
+  /* Avoid revealing the sandbox base address.
+   * In particular this means that we don't do the following:
+   *   movq 32(r15,rsi), r11
+   *   ...
+   *   movq r11, %nacl:32(r15,rdi)
+   * because the latter instruction might be reached via a direct or
+   * indirect jump when r11 contains the sandbox base address in its
+   * top 32 bits, and this would write the sandbox base address into
+   * memory.  We treat r11 as a write-only register to avoid
+   * revealing the sandbox base address to user code.
+   * Instead, we spill rdx and use that.
+   */
+  pushq    rdx
   .p2align 4
 loop:
   prefetchnta   768 (r15,rsi)
   prefetchnta   832 (r15,rsi)
 
   movq %nacl:      (r15,rsi), rax

[Mark Seaborn, 2015/02/11 02:23:45]

Aside: if we want to optimise this, we could use rbp as the address register, so
that the masking only happens once.

[Derek Schuff, 2015/02/11 23:16:06]

Done.

   movq %nacl:    8 (r15,rsi), r8
   movq %nacl:   16 (r15,rsi), r9
   movq %nacl:   24 (r15,rsi), r10
-  movq %nacl:   32 (r15,rsi), r11
+  movq %nacl:   32 (r15,rsi), rdx
   movq %nacl:   40 (r15,rsi), r12
   movq %nacl:   48 (r15,rsi), r13
   movq %nacl:   56 (r15,rsi), r14
 
   movntiq rax, %nacl:     (r15,rdi)
   movntiq r8 , %nacl:   8 (r15,rdi)
   movntiq r9 , %nacl:  16 (r15,rdi)
   movntiq r10, %nacl:  24 (r15,rdi)
-  movntiq r11, %nacl:  32 (r15,rdi)
+  movntiq rdx, %nacl:  32 (r15,rdi)
   movntiq r12, %nacl:  40 (r15,rdi)
   movntiq r13, %nacl:  48 (r15,rdi)
   movntiq r14, %nacl:  56 (r15,rdi)
 
   movq %nacl:    64 (r15,rsi), rax
   movq %nacl:    72 (r15,rsi), r8
   movq %nacl:    80 (r15,rsi), r9
   movq %nacl:    88 (r15,rsi), r10
-  movq %nacl:    96 (r15,rsi), r11
+  movq %nacl:    96 (r15,rsi), rdx
   movq %nacl:   104 (r15,rsi), r12
   movq %nacl:   112 (r15,rsi), r13
   movq %nacl:   120 (r15,rsi), r14
 
   movntiq rax, %nacl:  64 (r15,rdi)
   movntiq r8 , %nacl:  72 (r15,rdi)
   movntiq r9 , %nacl:  80 (r15,rdi)
   movntiq r10, %nacl:  88 (r15,rdi)
-  movntiq r11, %nacl:  96 (r15,rdi)
+  movntiq rdx, %nacl:  96 (r15,rdi)
   movntiq r12, %nacl: 104 (r15,rdi)
   movntiq r13, %nacl: 112 (r15,rdi)
   movntiq r14, %nacl: 120 (r15,rdi)
 
   leal    128 (rsi), esi
   leal    128 (rdi), edi
 
   dec     ecx
   jnz     loop
 
   sfence
-  movl    edx, ecx
+  popq    rcx
   andl    $127, ecx
   rep     movsb %nacl:(rsi), %nacl:(rdi), r15
   popq    r14
   popq    r13
   popq    r12
   popq    rax
   pop     r11
   nacljmp r11d, r15
 
 
 byte_copy:
   movl    edx, ecx
   rep     movsb %nacl:(rsi), %nacl:(rdi), r15

[Mark Seaborn, 2015/02/11 02:23:45]

This leaves base-address-extended addresses in registers.  You'll need to remove
use of REP instructions too.

See
https://docs.google.com/a/chromium.org/document/d/1eskaI4353XdsJQFJLRnZzb_YIE...

[Derek Schuff, 2015/02/11 18:19:11]

Would it be sufficient just to clear rsi and rdi after the movsb instruction?
The addresses are never written to memory in this case, and jumping to any of
these instructions would not result in the attacker getting the values from the
registers.

[Derek Schuff, 2015/02/11 18:36:00]

...except I guess if the movsb causes a fault, the user can catch it and get the
register state from the exception context.

[Mark Seaborn, 2015/02/11 19:21:51]

In principle, yes.  As you say, the instructions that clear rsi and rdi wouldn't
even need to be bundle-locked to the REP instruction.

However, checking for this is potentially more complicated to implement in the
validator.  It would be simpler just to disallow REP.

What would be the reason to keep the use of REP?  Is it just for ease of
porting, or do you think REP is faster than a loop these days?
Nope, that's not a problem, because we don't enable fault handling under PNaCl.

[Derek Schuff, 2015/02/11 23:16:06]

OK, as we discussed I just made them all explicit movs loops, and clear rsi and
rdi after exit.

   pop     r11
   nacljmp r11d, r15
 
 
 quadword_copy:
   movl    edx, ecx
   shrl    $3, ecx
   .p2align 4
   rep     movsq %nacl:(rsi), %nacl:(rdi), r15
   movl    edx, ecx
   andl    $7, ecx
   rep     movsb %nacl:(rsi), %nacl:(rdi), r15 /* Copy the remaining bytes */
   pop     r11
   nacljmp r11d, r15