[lkml]   [2011]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox
On 14 November 2011 00:38, Andrew Lutomirski <> wrote:
> On Sun, Nov 13, 2011 at 10:50 PM, Mark Seaborn <> wrote:
>> I think the problem is that seccomp-sandbox attempts to patch the
>> vsyscall page.  It replaces the SYSCALL instructions in this page with
>> jumps to seccomp-sandbox's handler.  (More accurately, seccomp-sandbox
>> creates a patched copy of the vsyscall page.  It redirects glibc's
>> indirect jumps so that they go to the patched copy of the vsyscall
>> page instead of to the original.)  The code for this is in
>> patchVSystemCalls() in
>> (
>> If the vsyscall page's code no longer invokes the kernel via SYSCALL
>> instructions but via some other trap, seccomp-sandbox's trick will no
>> longer work, because it doesn't know to patch the instructions that do
>> this new trap.
> The vsyscall code is now:
>        mov $__NR_whatever %rax
>        syscall
>        ret
> It used to be weirder, but we changed to to avoid breaking things like
> this.  The secret is that, if vsyscall=emulate, the vsyscall page is
> not executable and we use the page fault to invoke
> do_emulate_vsyscall.  But userspace can't tell it's not executable
> without actually jumping there, and with vsyscall=native, it's just a
> normal syscall.

Ah, that's much nicer. In that case, the fix should just be a case of
adding the new syscall numbers to the whitelist in

The current hang might just be occurring because libpthread's timeout
calculations come out wrong. libpthread doesn't check for errors from
its calls to vsyscall routines, at least in
nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S in the
version I checked.

> I'll try to build a sandboxing copy of chromium tomorrow to see if I
> can reproduce it.

You don't necessarily need to build Chromium. You can try running
"make test" in a checkout of seccompsandbox. That might not catch the
problem, though. I did not realise that the vsyscall page was still
used by glibc when I wrote those tests.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-11-14 17:29    [W:0.039 / U:0.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site