Closed Bug 1762540 Opened 2 years ago Closed 2 years ago

Avoid using SECCOMP_RET_KILL_THREAD

Categories

(Core :: Security: Process Sandboxing, enhancement, P1)

x86_64
Linux
enhancement

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox100 --- wontfix
firefox101 --- fixed

People

(Reporter: gcp, Assigned: jld)

References

Details

Attachments

(1 file)

Introduced in kernel 4.13 0466bdb99e8744bc9befa8d62a317f0fd7fd7421

Should be possible in a backwards-compat way:

    Asynchronous termination of a thread outside of the userspace thread
    library's knowledge is an unsafe operation that leaves the process in
    an inconsistent, corrupt, and possibly unrecoverable state.
....
    The new action is discoverable by userspace through either the new
    actions_avail sysctl or through the SECCOMP_GET_ACTION_AVAIL seccomp
    operation. If used without checking for availability, old kernels
    will treat RET_KILL_PROCESS as RET_KILL_THREAD (since the old mask
    will produce RET_KILL_THREAD).

This would solve problems where a sandbox violation makes new tabs hang due to dead locks, rather than producing a nice crash.

There was a question if SECCOMP_RET_TRAP could be invoked and then have that kill the process. I have no idea if that'd work.

See Also: → 1759196

SECCOMP_RET_KILL_THREAD is, as mentioned, bad because it results in mysterious hangs. (The first attempt at using seccomp-bpf with Gecko, on B2G, did that by default; that broke something I was testing, so I fixed it, and I ended up becoming the owner.)

SECCOMP_RET_KILL_PROCESS will at least kill the process, but it's not ideal, because we won't get a crash report.

The only use of SECCOMP_RET_KILL_THREAD I can see is in DefaultPanic, and we can override that externally via SetPanicFunc. I have a patch to do this, which I wrote while investigating bug 1759196, and it seems to work (with an artificial test case; I haven't tried to reproduce the original bug there with a patched build yet). So I'm going to take this bug and adjust the purpose a little.

Assignee: nobody → jld
Summary: Support SECCOMP_RET_KILL_PROCESS → Avoid using SECCOMP_RET_KILL_THREAD
Severity: -- → S3
Priority: -- → P1
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4745b182f545
Crash normally, instead of killing the calling thread, for certain sandbox errors. r=gcp
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: