Messages in this thread | | | Date | Mon, 14 Nov 2011 08:26:35 -0800 | Subject | Re: [3.1 REGRESSION] Commit 5cec93c216db77c45f7ce970d46283bcb1933884 breaks the Chromium seccomp sandbox | From | Mark Seaborn <> |
| |
On 14 November 2011 00:38, Andrew Lutomirski <luto@mit.edu> wrote: > On Sun, Nov 13, 2011 at 10:50 PM, Mark Seaborn <mseaborn@chromium.org> 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 library.cc >> (http://code.google.com/p/seccompsandbox/source/browse/trunk/library.cc). >> >> 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 system_call_table.cc.
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.
Cheers, Mark -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |