[3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox

[Nix <nix@esperi.org.uk>]

With this commit installed:

commit 5cec93c216db77c45f7ce970d46283bcb1933884
Author: Andy Lutomirski <luto@MIT.EDU>
Date:   Sun Jun 5 13:50:24 2011 -0400

    x86-64: Emulate legacy vsyscalls

With CONFIG_SECCOMP set, and the Chromium seccomp sandbox compiled in
and enabled (which is not the default), on a system running glibc 2.12.x
(thus, relying on emulated vsyscalls), Chromium renderers sometimes hang
or abruptly abort before rendering anything (both of which show as pages
that never complete rendering and eventually get a Chromium kill request
dialog). The hang is consistent for a given page, but not all pages
hang. (One that *does* hang is the chrome://extensions page, so network
access is not the problem here.)

vsyscall=native does not help.

Turning off CONFIG_SECCOMP, or running Chromium with the seccomp sandbox
disabled, fixes it.

I speculate that do_emulate_vsyscall() is broken, but it's hard to debug
the Chromium renderer sandboxing to see what's failing because the
multiple layers of sandboxing get in the way, as they are designed to :)
(also, I am not in any way shape or form a Chromium hacker). Chromium
does downright terrible things to convert syscalls into IPC calls
outside the seccomp sandbox (mostly to a separate, nonseccomped,
assembler thread in the same process, but in some cases via IPC to an
entirely separate process for validation followed by IPC back and
execution in that separate thread). I suspect this delicate dance (for
which see seccompsandbox/ in a Chromium source tree) has been disrupted.

I have raised Chromium bug
<http://code.google.com/p/chromium/issues/detail?id=104084> to attract
the Chromium hackers' attention to this, and am Cc:ing a Chromium hacker
whose fingers are all over the seccomp sandbox as well. Hopefully the
cause, or a diagnostic trick, will be obvious to someone other than me.

-- 
NULL && (void)