ASan doesn't play well with the seccomp-bpf sandbox (check failed: proc_self_maps_buff_len_)

[ramosian-glider]

Originally reported on Google Code with ID 106

I have been building ASAN-chrome with instructions from http://www.chromium.org/developers/testing/addresssanitizer

I'm using the newest prebuilt clang from http://commondatastorage.googleapis.com/chromium-browser-clang/index.html?path=Linux_x64/
(and also tried few earlier ones with same results)

I have multiple machines with Ubuntu 11.04 x86_64 and all those machines are working
ok.

On my Ubuntu 12.04 x86_64 version I can build the ASAN-chrome without error but when
I start up the chrome I get huge amount of the following AddressSanitizer CHECK failed
messages and after that chrome crashes.

==29268== AddressSanitizer CHECK failed: /usr/local/google/chrome/src/third_party/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:251
"((proc_self_maps_buff_len_)) > ((0))" (0x0, 0x0)
==29268== AddressSanitizer CHECK failed: /usr/local/google/chrome/src/third_party/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:251
"((proc_self_maps_buff_len_)) > ((0))" (0x0, 0x0)
==29268== AddressSanitizer CHECK failed: /usr/local/google/chrome/src/third_party/llvm/projects/compiler-rt/lib/sanitizer_common/sanitizer_linux.cc:251
"((proc_self_maps_buff_len_)) > ((0))" (0x0, 0x0)

I'm not sure what information I should provide or even if this is the correct place
to report the problem but I would highly appreciate if you could help with this issue.

Reported by attekett on 2012-09-01 10:07:00

[ramosian-glider]

Please make sure the SUID sandbox is off. There's an env var controlling it, something
like CHROME_DEVEL_SANDBOX

Reported by ramosian.glider on 2012-09-01 10:58:22

• Status changed: Accepted

[ramosian-glider]

As far as I know it should be disabled, but I made a new build, after export CHROME_DEVEL_SANDBOX=,
just to be sure. Still the same problem persists.

Reported by attekett on 2012-09-01 12:30:59

[ramosian-glider]

I'm trying to reproduce this now.
BTW have you tried the ToT Clang?

Reported by ramosian.glider on 2012-09-05 07:33:52

• Labels added: OpSys-Linux

[ramosian-glider]

I have only tried with the pre-built versions of clang for chromium-browser. I also
tried few of the newest ASAN-chromium builds from https://commondatastorage.googleapis.com/chromium-browser-asan/index.html
they give the same error.

Reported by attekett on 2012-09-05 09:23:06

[ramosian-glider]

Looks like you're hitting the seccomp BPF sandbox (I'm not really sure if the name is
correct), which requires kernel support that has appeared in Precise (12.04)
Here's what happens:

#10915 0x00007f3ac7e349c9 in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long) ()
#10916 0x00007f3ac7e37d3b in __sanitizer::ProcessMaps::ProcessMaps() ()
#10917 0x00007f3ac7e3554b in __asan::AsanStackTrace::PrintStack(unsigned long*, unsigned
long) ()
#10918 0x00007f3ac7e349c9 in __sanitizer::CheckFailed(char const*, int, char const*,
unsigned long long, unsigned long long) ()
#10919 0x00007f3ac7e37d3b in __sanitizer::ProcessMaps::ProcessMaps() ()
#10920 0x00007f3ac7e3554b in __asan::AsanStackTrace::PrintStack(unsigned long*, unsigned
long) ()
#10921 0x00007f3ac7e33ed3 in __asan::ReportSIGSEGV(unsigned long, unsigned long, unsigned
long, unsigned long) ()
#10922 0x00007f3ac7e3c1c6 in __asan::ASAN_OnSIGSEGV(int, siginfo*, void*) ()
#10923 <signal handler called>
#10924 0x00007f3ac3c8b96a in (anonymous namespace)::CrashSIGSYS_Handler(playground2::arch_seccomp_data
const&, void*) ()
#10925 0x00007f3ac6b41f17 in playground2::Sandbox::sigSys(int, siginfo*, void*) ()
#10926 <signal handler called>
#10927 __pthread_getaffinity_new (th=<optimized out>, cpusetsize=32, cpuset=0x7f3ab3604080)
at ../nptl/sysdeps/unix/sysv/linux/pthread_getaffinity.c:38
#10928 0x00007f3aba166b10 in pthread_getattr_np (thread_id=139890003711744, attr=0x7f3aadfa8b78)
at pthread_getattr_np.c:153
#10929 0x00007f3ac7e373cf in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned
long*, unsigned long*) ()
#10930 0x00007f3ac7e35ec3 in __asan::AsanThread::Init() ()
#10931 0x00007f3ac7e3604c in __asan::AsanThread::ThreadStart() ()
#10932 0x00007f3aba164e9a in start_thread (arg=0x7f3aadfa9700) at pthread_create.c:308

#10933 0x00007f3ab84fe4bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#10934 0x0000000000000000 in ?? ()

ASan calls __NR_sched_getaffinity, which is restricted by the sandbox (see http://code.google.com/searchframe#OAMlx_jo-ck/src/content/common/sandbox_seccomp_bpf_linux.cc),
then it receives a SIGSYS handler, which makes ASan print the stack trace. Because
ASan then tries to call __NR_open, which also fails under the sandbox, the program
falls into the endless recursion (open("/proc/self/maps") returns -1 -> call CheckFailed
-> open("/proc/self/maps") again)

The short-term solution for you is to run Chrome with the --no-sandbox commandline
flag. We'll try to work out something more feasible.

Reported by ramosian.glider on 2012-09-05 09:33:02

[ramosian-glider]

I tried with --disable-seccomp-sandbox before but it didn't have any effect. 

Looks like with --no-sandbox chromium starts up correctly, but it might cause some
other problems at least if you believe the warning chromium gives when run with the
--no-sandbox flag.  

Reported by attekett on 2012-09-05 09:46:58

[ramosian-glider]

Ok, instead you can try to hack http://code.google.com/searchframe#OAMlx_jo-ck/src/content/common/sandbox_seccomp_bpf_linux.cc
and add the following line:

  if ((sysno == __NR_open) || (sysno == __NR_sched_getaffinity)) return true;

at the beginning of IsBaselinePolicyAllowed_x86_64(). This will suppress these warnings,
but keep in mind you're making your Chrome vulnerable to attacks related to these syscalls
(which should be fine as long as you're just running your tests)

Reported by ramosian.glider on 2012-09-05 10:02:32

[ramosian-glider]

thanks for the tip. i'll try with --no-sandbox first, if I hit any "false" positives,
I'll try the hack.

Reported by attekett on 2012-09-05 10:08:58

[ramosian-glider]

Note that seccomp-bpf can be selectively disabled via --disable-seccomp-filter-sandbox.
If you're on a DEBUG build, the seccomp-legacy sandbox might kick-in so you may want
--disable-seccomp-sandbox as well.

--no-sandbox is a useful shortcut that disable the setuid sandbox *and*  the seccomp
sandboxes. Prefer it to unsetting the CHROME_DEVEL_SANDBOX variable, because at least
your intent becomes clear.

We should probably make this hack permanent in Chrome on condition that ASAN is compiled
in.

Reported by jln@chromium.org on 2012-09-05 19:00:52

[ramosian-glider]

Reported by ramosian.glider on 2012-10-29 11:42:38

[ramosian-glider]

Reported by ramosian.glider on 2012-10-29 11:47:08

• Labels added: Chromium

[ramosian-glider]

is this fixed? 

Reported by konstantin.s.serebryany on 2013-01-14 14:06:59

[ramosian-glider]

Let's say yes.
Although there's a minor problem with Chrome being unable to upload the crash dumps
if the sandbox is on (https://codereview.appspot.com/7066068/), there's nothing to
do on the ASan side.

Reported by ramosian.glider on 2013-01-14 14:09:21

• Status changed: Fixed

[ramosian-glider]

Issue 90 has been merged into this issue.

Reported by ramosian.glider on 2013-01-14 14:13:36

[ramosian-glider]

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:59

• Labels added: ProjectAddressSanitizer