1298869 - MOZ_CRASH(seccomp+tsync failed, but kernel supports tsync) when running with rr

Status: RESOLVED INVALID

(Core :: Security: Process Sandboxing, defect)

Description

[Botond Ballo [:botond]]

STR:
  1. Install rr (http://rr-project.org/)
  2. Run a local build of m-c with |mach run --debugger rr|
  3. Load any webpage

Expected results:
  The page loads.

Actual results:
  The content process crashes, with the following output:

Sandbox: thread-synchronized seccomp failed: Function not implemented
Hit MOZ_CRASH(seccomp+tsync failed, but kernel supports tsync) at /home/botond/dev/mozilla/central/security/sandbox/linux/Sandbox.cpp:452

Running without rr works fine.

Setting security.sandbox.content.level=0 fixes the problem.

Comment 1

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

This is a bug in rr.  Also, there's a better workaround: set MOZ_FAKE_NO_SECCOMP_TSYNC in the environment.


What seems to be going on here is: 

* The sandbox feature detection code passes nullptr instead of an actual filter and checks for EFAULT, in order to probe for support without actually changing the process state.  Chromium also uses this technique (and seccomp-bpf was originally contributed to Linux by the Chromium project, so they'd know as well as anyone).

* rr tries to emulate the seccomp syscall (which is needed in order to use the SECCOMP_FILTER_FLAG_TSYNC flag, to change all threads in the process at once; this is the "tsync" feature referred to in the error message) without first checking if it's supported, and it has an early exit that returns a synthetic EFAULT if the filter address is invalid, even if the actual syscall wouldn't have gotten that far: https://github.com/mozilla/rr/blob/3d96a37cc/src/SeccompFilterRewriter.cc#L38

* In this case the kernel *doesn't* support it, but rr's interposition returns a false positive to the detection code, so when the time comes to actually install the filter, rr needs to use the actual syscall to install its patched version of the filter program, and that does fail with ENOSYS.

* This would also be the case for the older prctl(PR_SET_SECCOMP, ...) interface, but kernels old enough to lack seccomp-bpf entirely are uncommon enough that perhaps nobody has ever tried to run Firefox under rr on one.

I'd suggest that rr should either probe for syscall support before trying to interpose like that, or else change those early returns to cause the recorded process to issue the syscall itself so that it gets the appropriate error.

Additionally, it seems that rr isn't handling SECCOMP_FILTER_FLAG_TSYNC correctly, in that it's not handling it at all — it seems to be completely ignoring the flags argument and marking only the calling thread as having changed seccomp status, but passes through the flags to the actual syscall, which means that other threads will get incorrect values from prctl(PR_GET_SECCOMP), which is trapped and emulated by rr.

(Disclaimer: everything in this comment is from code reading, not testing.)

Comment 2

[Botond Ballo [:botond]]

Thanks for the analysis! I filed an rr bug: https://github.com/mozilla/rr/issues/1781

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

rr doesn't work without seccomp-bpf, that's why we don't have issues on them :-).