Issue 106 in address-sanitizer: check failed: proc_self_maps_buff_len_

[address-...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 106 by attek...@gmail.com: check failed: proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?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.

[address-...@googlecode.com]

Updates:
Status: Accepted
Owner: ramosian...@gmail.com

Comment #1 on issue 106 by ramosian...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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

[address-...@googlecode.com]

Comment #2 on issue 106 by attek...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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.

[address-...@googlecode.com]

Updates:
Labels: OpSys-Linux

Comment #3 on issue 106 by ramosian...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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

[address-...@googlecode.com]

Comment #4 on issue 106 by attek...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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.

[address-...@googlecode.com]

Comment #5 on issue 106 by ramosian...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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.

[address-...@googlecode.com]

Comment #6 on issue 106 by attek...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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.

[address-...@googlecode.com]

Comment #7 on issue 106 by ramosian...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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)

[address-...@googlecode.com]

Comment #8 on issue 106 by attek...@gmail.com: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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

[address-...@googlecode.com]

Comment #9 on issue 106 by j...@chromium.org: check failed:
proc_self_maps_buff_len_
http://code.google.com/p/address-sanitizer/issues/detail?id=106

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.