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

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

On 14 Nov 2011, Andrew Lutomirski stated:

> 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.

I grepped for vsyscall to try to avoid making an idiot of myself like
this. A shame I misspelt it. :/

> 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.
>
> I'll try to build a sandboxing copy of chromium tomorrow to see if I
> can reproduce it.

If you look at line 909 of seccompsandbox/library.cc (in
http://git.chromium.org/external/seccompsandbox.git) the problem does
indeed jump out at you. That nice manual disassembly using == isn't
going to work anymore. It even helpfully dies with a message saying that
it can't patch the vsyscall page, but the message gets thrown away by
some higher layer.

I suspect we want two functions and something to recognize what the
vsyscall page looks like and choose between them, rather than making
this already tricky function even uglier.

(To build Chromium with sandboxing, the recipe is little more than
making sure you haven't passed in -Dselinux, and starting Chromium with
--enable-seccomp-sandbox. It's turned off by default because it slows
Chromium down, not because it doesn't work. :) )

-- 
NULL && (void)