The sandbox does not intercept glibc's calls to the x86-64 vsyscall page

[GoogleCodeExporter]

In Ubuntu Lucid, libpthread contains calls to the x86-64 vsyscall page:

$ objdump -d /lib/libpthread.so.0
...
    ae50:       48 c7 c0 00 00 60 ff    mov    $0xffffffffff600000,%rax
    ae57:       ff d0                   callq  *%rax
...
(This is a call to vgettimeofday.)

When I disassemble these functions in a sandboxed process using gdb, I can see 
that the SYSCALL instructions have been patched, but the indirect calls to the 
vsyscall page have not.  There is code in library.cc for patching indirect 
calls, but it is only enabled for patching the vdso.

In practice, the vsyscall calls seem to be conditional on 
__have_futex_clock_realtime being false.  libpthread won't call vgettimeofday 
on a kernel that supports FUTEX_CLOCK_REALTIME.

This issue might be behind the problem with Linux 3.1 (issue chromium:104084), 
but I need to investigate more.

This is a difficult problem to solve in general, because it's probably not 
practical to enable library.cc's indirect-call patching code for libpthread.so 
or libc.so.  The kernel does not allow us to patch the vsyscall page (which is 
in the kernel range of address space), unlike the vdso.  However, the vsyscall 
page is deprecated, so we probably don't need to handle the general case.

Original issue reported on code.google.com by mseaborn@chromium.org on 15 Nov 2011 at 5:10

[GoogleCodeExporter]

Original comment by mseaborn@chromium.org on 15 Nov 2011 at 5:49

[GoogleCodeExporter]

libc.so contains a couple of unconditional calls to the vsyscall page that we 
need to patch, for time() and sched_getcpu().

$ objdump -d /lib/libc.so.6
...
0000000000099ed0 <time>:
   99ed0:       48 83 ec 08             sub    $0x8,%rsp
   99ed4:       48 c7 c0 00 04 60 ff    mov    $0xffffffffff600400,%rax
   99edb:       ff d0                   callq  *%rax
   99edd:       48 83 c4 08             add    $0x8,%rsp
   99ee1:       c3                      retq   
...

This definitely breaks on Linux 3.1, where vtime always executes a SYSCALL 
instruction.

I suggest we handle these two cases by making the patcher look for this 
instruction sequence:
  mov $0xffffffffff600x00,%rax
  callq *%rax

Original comment by mseaborn@chromium.org on 15 Nov 2011 at 6:15

[GoogleCodeExporter]

Original comment by mseaborn@chromium.org on 17 Nov 2011 at 5:09

• Changed state: Started

[GoogleCodeExporter]

Fixed in r178.

Original comment by mseaborn@chromium.org on 19 Nov 2011 at 4:31

• Changed state: Fixed